Software Vault: The Diamond Collection/The Diamond Collection (Software Vault)(Digital Impact).ISO/cdr36/famedemo.zip/FAMOUS.DOC

Text File | 1994-07-06 | 129KB | 3,053 lines

             FAMOUS is Copyright (c) 1993, 1994 by John Schachat


                       Documentation for FAMOUS 2.0
               Facilitate All Management Of User Services
                            By John Schachat


Author's Note:

Congratulations!  You have just purchased the most powerful, flexible
and reliable user manager EVER created for TBBS.  With FAMOUS you will
find that you can do more with your system than you ever dreamed and
find out more about your system and users than you ever knew before.

FAMOUS' flexibility allows many advanced features and capabilities.  The
price you pay is that you MUST understand what it is capable of
accomplishing in order to receive it's full benefit. Please take the
time to read through the docs and experiment with it's capabilities.
And, if you have any problems, or ideas/suggestions on how the
application might be improved, please don't hesitate to leave me a
message on the GWA board, or call my board at [phone].

Thank you for purchasing FAMOUS!

John

Another Note:

As FAMOUS evolves, changes are continually made and new features added.
These changes are documented in a history file called CHANGES.DOC which
is included with every update, as well as in this package.  Whenever you
receive an update, please take the time to read the CHANGES.DOC file.
There is also a file called HINTS.TXT which is some of the accumulated
wisdom from FAMOUS sysops.  HINTS will constantly be updated and
included in each revision package. Feel free to send me your
contributions for this file.


Conventions:
Anything enclosed in Square brackets [] is an Optional parameter
Anything enclosed in Triangular brackets <> is a Mandatory parameter
Anything separated by a Pipe | means OR.

These symbols (Brackets/Pipe) are never included in either the DOS
command line or the TBBS Opt Data line!

So, if the choice was AGER <//F:60> [USA|UPDATE]

This tells us that the program name is AGER, that the //F:60 is a
mandatory parameter and must be included in the command line. And that
either USA or UPDATE may also be included in the command line since they
are optional.

The actual DOS command could then be either:

 AGER //F:60

 OR

 AGER //F:60 USA

 OR

 AGER //F:60 UPDATE


Installation:

Contained in the archive are a number of .TPG programs, one .EXE program
used for your nightly event, one .EXE to convert data from other User
Management programs and one .EXE program used to define labels and
reports for offline printing, as well as a number of databases (.DBF)
files used by the system.

To Install, create a separate subdirectory for your FAMOUS files, and
place all the files in it. Like: C:\FAMOUS\.  Make sure that you keep it
near the top of your disk so that more parameters can be held in the Opt
Data line.  Remember that the TBBS Opt Data line can only pass 64
characters including the path name.  In the FAMOUS directory, create a
subdirectory call \INVOICE.  This will be used to store hard copies of
all invoices.

In your CONFIG.SYS file, install the ANSI.SYS device driver if you plan
to use the Console Alert Message Function.  Also make sure that your
FILES= statement is set to AT LEAST 100.

If you are using a LAN and have SHARE installed, make sure that the /F
parameter is set to AT LEAST 4096.  ESoft has reported that TBBS and
share don't exactly hit it off and you may recieve sporadic error
messages otherwise.  In some situations you may have to have the /F
parameter as high as 8192.  Unfortunately it is purely trial and error
to find the right setting.

It is highly recommended that the BBS system use a Disk Cache and
a 386 or better CPU.  TBBS releases greater than 2.2 will, in fact,
REQUIRE a 386 or better computer.

It is also a good idea to back up the .DBF files nightly, since these
contain critical information that you can't afford to lose.

Program Modules

Don't be frightened becauses you see so many .TPG files.  Most of them
are sub-modules which are called by the Main FAMOUS programs.  The only
ones you actually HAVE to put into your SDL are:

FAMFAST  - LOGON/LOGOFF AUTOEXECUTE MODULE
FAMSYSOP - SYSOP MODULE

Other modules which you may want to use are:

FAMUSER  - USER PROFILE REVISION MODULE
FAMBUYER - ALLOWS USERS TO BUY SERVICES
FAMCOSYS - COSYSOP MODULE. PROVIDES LIMITED ACCESS TO USER RECORDS.
USERSTAT - ALLOWS USERS TO SEE VARIOUS SYSTEM STATS
USERVIEW - ALLOWS USERS TO SEE VARIOUS USER STATS
GIFT     - ALLOWS YOU TO USE THE MAIL CODE FEATURE
FASTACCT - SHOWS NEW PURCHASES NEEDING AUTHORIZATION
FASTOWED - SHOWS NEW BUSINESS
FAMPASS2 - FORGOTTEN PASSWORD MODULE
EXPCHNG  - INSERTS EXISTING USERLOG EXPIRATION DATE INTO FAMOUS
FAMTABS  - PROVIDES TABS SUPPORT
INVVIEW  - ALLOWS USER TO VIEW/RETRIEVE PAST INVOICES

SDL

I have included a sample SDL file called FAMOUS.SDL.  When compiled it
will create a menu called MENUFAM.CTL.  This file contains sample
entries for all the FAMOUS programs you will need to invoke.  The menu
does not have any restrictions in it, so make sure that you do not make
it available to your users.  It is just to give you an idea of how to
call the various programs and lets you get going quickly.  In the SDL
make sure that you modify the EQUATE statements and the RIP macro to
reflect your system's configuration before compiling. The menu displays
are also included and are named FAMDEM.ANS/ASC/TXT/RIP

In a nutshell, here is where FAMOUS' menu entries normally go in YOUR
SDL:

*************************In Menu0000:*******************************

Entry: Mail Code Checking - Optional
Key=^@
Type=200
Priv=0  A1=-------- A2=-------- A3=-------- A4=-------- IBM=- ANS=-
Opt Data=C:\FAMOUS\GIFT /Q
; Optional parameters: None

Entry: FAMFAST Logon Routine
Key=^@
Type=200
Priv=0  A1=-------- A2=-------- A3=-------- A4=-------- IBM=- ANS=-
Opt Data=C:\FAMOUS\FAMFAST /Q && %BPS%   -%LOGGEDON%
; Optional parameters: -NC -NH -LOGOFF


The entry below is used if you are using FAMOUS' ability to tell users
that they have to use a two word name by using the -NH switch.  Like
John Smith instead of Smithy.

In this case, new users would have A1(1) turned on if they successfully
register in which case the type 45 doesn't activate.  If the No Handle
function activates they will be forced to relogon and be sent back to
the top of menu0000 where they will have to re-register via the Type 45.

Entry: Type 45 when -NH is used
Key=^@
Type=45
Priv=0  A1=.------- A2=-------- A3=-------- A4=-------- IBM=- ANS=-
Opt Data=0000
; Optional parameters: None

These next two entries are optional and provide TABS support.
See the TABS section for more information.

Entry: TABS
Key=^@
Type=200
A1=X.......
Priv=0
Opt Data=C:\TABS\TABS /Q

Entry: FAMTABS
Key=^@
Type=200
A1=X......X
Priv=0
Opt Data=C:\FAMOUS\FAMTABS /Q && TAB


This entry will display users who have birthdays today to all callers.
It is created during the nightly event <Optional Entry>

Entry: Display Today's Birthdays - Usually used as an autoexecute at logon
Key=^@
Type=1
Priv=0  A1=-------- A2=-------- A3=-------- A4=-------- IBM=- ANS=-
Opt Data=C:\FAMOUS\BDAY.TXT /NB/NBC


These next 2 should be protected by Priv=255 so that only the Sysop sees
them.

Entry: Fast Accounting. Only activates when purchases need to be authorized
Key=^@
Type=200
Priv=255  A1=-------- A2=-------- A3=-------- A4=-------- IBM=- ANS=-
Opt Data=C:\FAMOUS\FASTACCT /Q
; Optional parameters: None

Entry: Fast Owed. Only activates to show new purchases
Key=^@
Type=200
Priv=255  A1=-------- A2=-------- A3=-------- A4=-------- IBM=- ANS=-
Opt Data=C:\FAMOUS\FASTOWED /Q
; Optional parameters: None

These entries are normally followed by a type 35 command to switch
control to your Normal top menu so that a user only hits Menu0000 as he
first logs on to your system.

Entry: Type 35 to Top menu
Key=^@
Type=35
Priv=0  A1=-------- A2=-------- A3=-------- A4=-------- IBM=- ANS=-
Opt Data=MAIN
; Optional parameters: Name of your Main Menu

*********************In Your Sysop Menu:***************************

Entry: <1> FAMOUS Sysop Module
Key=1
Type=200
Priv=255  A1=-------- A2=-------- A3=-------- A4=-------- IBM=- ANS=X
Opt Data=C:\FAMOUS\FAMSYSOP /Q
; Optional parameters: None


*********************In Your Co-Sysop Menu:************************

Entry: <2> FAMOUS Co-Sysop Module
Key=2
Type=200
Priv=0  A1=-------- A2=-------- A3=-------- A4=-------- IBM=- ANS=X
Opt Data=C:\FAMOUS\FAMCOSYS /Q && -NOPASS -NOCC
; Optional parameters:  -NOCC and/or -NOPASS


********************In User Accesssible Menus:*******************

Entry: <5> Revise your Profile
Key=5
Type=200
Priv=0  A1=-------- A2=-------- A3=-------- A4=-------- IBM=- ANS=-
Opt Data=C:\FAMOUS\FAMUSER /Q && -REVISE

Entry: <6> View Top 50 User Statistics
Key=6
Type=200
Priv=0  A1=-------- A2=-------- A3=-------- A4=-------- IBM=- ANS=-
Opt Data=C:\FAMOUS\USERVIEW /Q && 50 -UP -DOWN -CALLS -TIME
; Optional parameters: # of Users -UP  -DOWN -TIME -CALLS -USER

Entry: <7> View System Statistics
Key=7
Type=200
Priv=0  A1=-------- A2=-------- A3=-------- A4=-------- IBM=- ANS=X
Opt Data=C:\FAMOUS\USERSTAT /Q
; Optional parameters:  -STAT  -TIME -AVGTIME

Entry: <8> View Your Personal Statistics
Key=8
Type=200
Priv=0  A1=-------- A2=-------- A3=-------- A4=-------- IBM=- ANS=-
Opt Data=C:\FAMOUS\USERVIEW /Q &&  -USER
; Optional parameters:  -UP  -DOWN -TIME -CALLS -USER

Entry: <9> Buy a Service or Product
Key=9
Type=200
Priv=0  A1=-------- A2=-------- A3=-------- A4=-------- IBM=- ANS=-
Opt Data=C:\FAMOUS\FAMBUYER /Q
; Optional parameters:  3 character category name

Entry: <B> Review/Download Past Invoices
Key=B
Type=200
Priv=0  A1=-------- A2=-------- A3=-------- A4=-------- IBM=- ANS=-
Opt Data=C:\FAMOUS\INVVIEW /Q
; Optional parameters:  None

Entry: <A> Forgotten Password Module
Key=A
Type=200
Priv=0  A1=-------- A2=-------- A3=-------- A4=-------- IBM=- ANS=-
Opt Data=C:\FAMOUS\FAMPASS2 /Q  && -MSG
; Optional parameters: -MSG -LOGOFF


Note that the USERSTAT and USERVIEW modules have a number of different
Switches which may be used.  This lets you have more SDL entries to show
users different facets of your system or restrict them from seeing some
of the entries.  You can also separate them more and have more menu
entries so that each entry only calls one stat display.

*******************In your Final Logoff Menu:*******************

Entry: FAMFAST Logoff Routine
Key=^@
Type=200
Priv=0  A1=-------- A2=-------- A3=-------- A4=-------- IBM=- ANS=-
Opt Data=C:\FAMOUS\FAMFAST /Q && %BPS%  -LOGOFF
; Optional parameters: -NC -NH -LOGOFF

**********************************************************************

About your LOGOFF Menu:

I have found that it is much better to actually have 2 logoff menus which
function similarly to your 2 top menus.

The first logoff menu would NOT contain a type 10 command.  It might
have functions such as:

<S>end a Message to the Sysop
<R>eturn to the Last Menu
<G>o to the Main Menu
<L>ogoff Immediately

These are all the normal commands you would expect except that
<L>ogoff Immediately DOES NOT invoke a type 10 command.  Instead, it
invokes a type 5 which immediately sends you to a secondary logoff menu.

On this secondary Logoff menu you would have 2 autoexecutes:

MENU: OFF2

Entry: FAMFAST Logoff Routine
Key=^@
Type=200
Priv=0  A1=-------- A2=-------- A3=-------- A4=-------- IBM=- ANS=-
Opt Data=C:\FAMOUS\FAMFAST /Q && %BPS%  -LOGOFF
; Optional parameters: -NC -NH -LOGOFF

Entry: Logoff System
Key=^@
Type=10
Priv=0  A1=-------- A2=-------- A3=-------- A4=-------- IBM=- ANS=-
Opt Data=

ENDMENU:

This is so the user never hits the FAMOUS logoff module until he REALLY
is logging off your system.  It's not really a big deal, but it does
insure that FAMFAST doesn't run until the user is REALLY logging off.
You could even put in a customized Type 1 autoexecute within a final
logoff menu. If you do this you may want to use the /NB/NBC/NK switches
so that the message doesn't go against the users download bytes and they
don't get the -Press Any Key- prompt.


About the Programs:


AGER.EXE - Performs all nightly aging, printing and maintenance
           functions when run from your RUNBBS.BAT file. These
           operations and their frequency are controlled by the online
           Sysop module.  AGER is also able to update USERLOG.BBS with
           the user's current parameters that you have entered into his
           profile in the FAMOUS database.

  During it's operation, AGER opens up many files at a time.  Be sure
  that your 'FILES='  Statement in Config.Sys is set to at least 100 for
  proper operation.

  Before AGER is called in your .BAT file, make sure that you do a CD to
  the FAMOUS directory.

  AGER always needs to have on it's command line //F:60 at the beginning,
  in addition to any other parameters. This allows the program to grab
  up to 60 DOS handles, which it needs in order to be able to open up
  all the files it requires.  Each parameter must always be
  separated by a single space.  You must also Change to the FAMOUS
  directory prior to running AGER.

  Like:
  CD C:\FAMOUS
  AGER.EXE //F:60

  NOTE: It is important that AGER run BEFORE ULEDIT /U in your
  RUNBBS.BAT file.  This is so it can find deleted users in the
  userlog and delete them from the FAMOUS database before they are
  permanently removed by ULEDIT.

  Important Note:  FAMGHOST MUST ALWAYS RUN AFTER AGER RUNS. This is to
  guarantee index file compatibility.  I HAVE found differences between
  Clipper-created index files and TDBS-created index files that can
  cause sporadic errors under certain conditions. By running FAMGHOST,
  you guarantee the integrity and compatibility of these files.  See the
  Indexing section for more information on your index options.

  If this is a new installation, and there is no need for conversion, do
  not run AGER prior to running the online TPG modules. Doing so will
  result in an error message until the NDX files are built either by
  FAMGHOST or FAMSYSOP.


Operation as a Nightly Event:

  For normal operation, running as a nightly event, it requires no
  command line parameters and would be run from your RUNBBS.BAT file as
  AGER.EXE //F:60 [USA]. Note that the brackets are never included in a
  FAMOUS command or Opt Data line.

  The parameter USA is used for the demographic reporting and will
  disregard the country field when tallying zip code demographics.


CONVERT.EXE
        1. It can import mailing lists which are prepared as
        comma-delimited text files.

        2. It can import user data from the TUIMS or UM databases into
        FAMOUS.

Importing User Data from a Text File.

  CONVERT.EXE //F:60 <Path/Name of mailing list text file> [Delimiter]
  [mailing list group]

  for example, if the list were comma/quote-delimited, it's name were
  MAIL.TXT and you wanted imported users to be identified as coming from
  the Frostbite mailing list you would run CONVERT as follows:

  CONVERT.EXE //F:60 MAIL.TXT " FrostBite

  In this case, that lone quote says that each field is comma delimited
  and each field is encased with a double quote.

  like "John Schachat", "123 Maple Lane", "San Jose", "CA", "95124"

  or it could be like:

  John Schachat, 123 Maple Lane, San Jose, Ca, 95124

  even with the quote in the command line


  The format of the information must always be:

  Full Name, Street Address, City, State, Zip


Importing Data from UM or TUIMS

  When importing user data from UM or TUIMS, CONVERT will accept a
  different set of command line parameters.

  CONVERT.EXE //F:60 <CONVERT> <UM2|UM3|TUIMS> <ENCRYPT|NOENCRYPT> <Path of
  TUIMS|UM followed by a \>

  The keyword CONVERT identifies this as a conversion operation, next
  you select either UM2, UM3 or TUIMS as the conversion source, you tell
  CONVERT whether you wish to import/not import credit card numbers -
  ENCRYPT will import them, NOENCRYPT won't, as they will be useless if
  they have been encrypted since you won't be able to tell what they
  are. The next time a user uses his credit card, however, this field
  will be refreshed with the new credit card information. Finally enter
  the DOS path, followed by a trailing \, where the UM/TUIMS databases
  are located.

  Like:

  CONVERT.EXE //F:60 CONVERT UM3 NOENCRYPT C:\TBBS\UM\

  The Conversion operation will not affect the source databases in any
  way.  Following conversion, it will be necessary to inspect the FAMOUS
  databases, through FAMSYSOP, and make any editing changes that are
  required. CONVERT does it's best to convert as much as possible, but
  because there are significant differences between the operation of
  FAMOUS and UM/TUIMS, not all items will come across completely.

  For a UM->FAMOUS conversion:

  1. Most user information is converted including the expiration date,
  renewal date, etc.  Most remaining user information will be updated
  and added to his record the next time he logs on.

  2. The Trash Can is completely converted.

  3. Checks/Deposits are completely converted.

  4. An attempt is made at converting Fee levels
  into Services.  These need to be verified and edited.


  For a TUIMS->FAMOUS conversion:

  1. Most user information is converted including the expiration date.
  Most remaining user information will be updated and added to his
  record the next time he logs on.

  2. The Trash Can is converted.  Any numeric field, i.e. 6969696 will be
  assumed to be a credit card.  Any field which which contains alpha
  information, i.e. Wang, is assumed to be a word or phrase.  Editing
  may be required following conversion.


  Conversion Notes:

  FAMOUS' conversion routines do a fairly good job of moving user
  information from UM/TUIMS into the FAMOUS databases.  But there are
  very big differences in the way FAMOUS uses services versus the way
  other programs use fee levels. What this means is that while the
  user's various privileges remain intact as well as his current
  expiration date, etc.  FAMOUS will not have a service assigned to that
  user designating his current level.  This is OK, but it means that
  your reporting won't track your service levels.  There is, however,
  a way around this.  You have the ability to batch assign services to
  people based on their PRIV level.  Furthermore, you may specify that
  the user's existing expiration date override and replace the service
  expiration date as specified in the service definition.  For example,
  Let's say you've just converted from another package.  In that
  package you had 100 users who had bought your premium level.  You now
  want to Flag them in FAMOUS, but not change anything else.  Here's
  what you would do:

  1. Create a Service.
  2. Give it a description, like Premium Service Level
  3. Give it a Code like PRM
  4. Make it Active, but do not make it available to your users as this
     service won't really do anything.
  5. Give it a Priv window from 0 to 255
  6. You might want to have it go to another service when it expires, or
     not.  This would allow you to display a file telling the user that
     his subscription had expired or downgraded his privileges.
  7. You probably will want to accept the rest of the defaults, as we
     don't really want to change the user's capability.
  8. When you're finished defining the service, go to the user
     information screen and Batch assign the service.
  9. Enter in the PRIV level for your Premium users, the service code,
     PRM in this example, and elect to make the expiration date of the
     service = your users' existing expiration dates.

  When it runs, FAMOUS will assign this dummy service to all premium
  users.  The service expiration date will be equal to your users'
  expiration dates, and you will be able to report, make labels, track,
  etc. all the Premium users on your system.  The same strategy can be
  used for your various other user groups as long as they have unique
  Priv levels.

 Converting from a System with no previous User Management Software

 One of the  major difficulties that people have when converting from an
 existing system with no user management software is what to do about
 the expiration date in the TBBS Userlog.bbs.  Many people have used
 this expiration date to expire users, even though it will permanently
 lock that user out of their system when the expiration date is hit.
 Something that is usually undesireable. With FAMOUS, you can expire
 users without permanently removing them from your system.  But then you
 have to change the TBBS expiration date to 00/00/00 so that TBBS
 doesn't expire them before they actually get in.  To aid in this
 process, I have included a small utility program call EXPCHNG.TPG.  You
 do NOT need to use it, but if you do, please follow the set of
 directions in the next three paragraphs.

 Make it an autoexecute that runs AFTER FAMFAST in your top menu.  It is
 VERY Fast and virtually invisible and does not require any parameters
 except /Q. It is even faster if the user DOES NOT have an expiration
 date set in the TBBS userlog, i.e. 00/00/00 or has been converted
 already. Which is where all your users will eventually end up. Works
 like this:

    Entry: Main FAMOUS logon module
    Key = ^@
    Type = 200
    Opt Data = C:\FAMOUS\FAMFAST /Q  && %BPS%    -%LOGGEDON%

    Entry: Converts TBBS Expiration Date
    Key = ^@
    Type = 200
    Opt Data = C:\FAMOUS\EXPCHNG /Q

 This utility will look for users who have a value other than 00/00/00
 in their TBBS expiration date field in Userlog.bbs.  If that value is
 00/00/00, the program will immediately quit. Otherwise, it will find
 them in the FAMOUS database and replace the FAMOUS expiration date with
 the one that is in the Userlog. It will then replace the userlog value
 with 00/00/00.

 If you leave this in for a few months, just guessing, the large bulk,
 or maybe all, of your users will have their expiration dates converted.
 All they have to do is hit it one time, at logon, and they're
 converted.  This is NOT a batch program and only does the conversion
 when a user logs in.  But it will get the job done painlessly and
 without any manual intervention.

FAMFAST.TPG

    FAMFAST is the Logon/Logoff module.  FAMFAST will quickly determine
    a user's status, update their records, check for RIP if you have it
    turned on, Display the logon files, if they are present, and send
    the user on his/her way.

    FAMFAST can use three optional switches which must be set up in a
    specific way:

    %BPS% is ALWAYS the first Switch.

    -%LOGGEDON% is ALWAYS the last switch

    -NC, -NH are always in the middle and separated by 2 spaces from
    %BPS% and -%LOGGEDON

    -LOGOFF is used only when FAMFAST is called at logoff.  When this
    switch is used, the only other switch used is %BPS%.

    Switch meanings:  The only 2 switches that need to be discussed are
    -NC and -NH.  The others pass logon data to FAMOUS.

    -NC prevents FAMOUS from collecting call information.  This has
    several effects.

    1. Logons are slightly faster
    2. Less Disk space is used
    3. But Many of FAMOUS' statistics will not be available or accurate

    It is reccomended that you DO NOT use the -NC switch unless it is
    absolutely necessary as you will lose a lot of valuable information.

    -NH prevents users with a priv less than 255 from using Single word
    names (Handles).  If it is used, the FAMFAST entry should be
    followed by a type 45 command that will return the user to the top
    menu.  Like:

    Entry: Returns User to TOP menu if they failed the No Handle test
    Key=^@
    A1=.-------
    TYPE=45
    OPT DATA=0000

    In this example, FAMOUS is turning on the A1(1) flag if the user
    successfully registers.


For Normal Logon Operation:
  Opt Data = C:\TBBS\FAMOUS\FAMFAST /Q && %BPS%   -%Loggedon%

  or for no Call Info Gathering:

  Opt Data = C:\TBBS\FAMOUS\FAMFAST /Q && %BPS%  -NC  -%Loggedon%

  or for no Call Info Gathering and no Handles:

  Opt Data = C:\TBBS\FAMOUS\FAMFAST /Q && %BPS%  -NC-NH  -%Loggedon%

  or for just no Handles:

  Opt Data = C:\TBBS\FAMOUS\FAMFAST /Q && %BPS%  -NH  -%Loggedon%


For Logoff:
  Opt Data = C:\TBBS\FAMOUS\FAMFAST /Q && %BPS%  -LOGOFF


FAMUSER.TPG
    This program is the interface for users to revise their profile.

    Put it in one of your user utility menus where a user can manually
    revise his/her profile on demand.  Like:

    Entry: <R> Revise your User Profile
    Key = R
    Type = 200
    Opt Data = C:\FAMOUS\FAMUSER /Q  && %BPS%  -REVISE


FAMSYSOP.TPG

   This is the Sysop control module and should be placed in your Sysop
   Menu where ONLY Sysops may access it.  It requires no additional
   command line parameters and calls other program modules.  Like:


   Entry: <F> FAMOUS User Management
   Priv=255
   Key = F
   Type = 200
   Opt Data = C:\FAMOUS\FAMSYSOP /Q


FAMBUYER.TPG

   This is the module which allows users to purchase services you
   define.  It requires no command line parameters and would normally be
   placed in one of your user menus.  Like:

   Entry: <P> Purchase System Services
   Key = P
   Type = 200
   Opt Data = C:\FAMOUS\FAMBUYER /Q && [3 character Category Name]

   The 3 character category name, which is matched with the one you have
   entered into a service definition, is used in combination with an Opt
   Data parameter in FAMBUYER to only display those services that match
   the supplied Category.  For example, you could have subscription
   services, file download services, Free Services, etc. Then you could
   display a menu to your users with multiple Calls to FAMBUYER on it,
   each identifying a specific category.

    If no category name is contained in the Opt Data line, the category
    function is ignored and all services are displayed.

    This capability also lets you protect different service offerings
    with FLAGS and PRIVs, via TBBS menu entries, as well as the
    internal Priv Window in each service.

    The Opt Data line is Formatted like:

    Opt Data=C:\FAMOUS\FAMBUYER /Q && [3 Character Category Name]

    Examples:

    Entry: <S> Subscribe and become a Member
    Key=S
    Type=200
    Priv=10
    A1=X..-----
    Opt Data=C:\FAMOUS\FAMBUYER /Q && SUB

    Entry: <F> Free Stuff
    Key=F
    Type=200
    Priv=50
    A1=X..----- A2=-------X
    Opt Data=C:\FAMOUS\FAMBUYER /Q && FRE

    Entry: <B> Buy More Download Time
    Key=B
    Type=200
    Priv=10
    A1=X..-----
    Opt Data=C:\FAMOUS\FAMBUYER /Q && FDL

    Entry: <V> View All Service Offerings
    Key=V
    Type=200
    Priv=10
    A1=X..-----
    Opt Data=C:\FAMOUS\FAMBUYER /Q


FAMGHOST.TPG

   This program may be run as a TBBS Ghost event or from a Sysop menu.
   It's sole purpose is to reindex the FAMOUS database files. When it is
   in use, you should be sure that no users are logging on/off of your
   system or buying Services.  Otherwise they will encounter a system
   Maintenance message and will be held until indexing is complete. They
   Will not encounter an error condition, however. (See the Indexing
   section for more information). It requires no command line
   parameters.

   Entry: <R> Re-index FAMOUS Databases
   Priv=255
   Key = R
   Type = 200
   Opt Data = C:\FAMOUS\FAMGHOST /Q

   It is important that FAMGHOST ALWAYS runs as a ghost after AGER runs
   during a nightly event. If you want FAMGHOST to always run
   automatically every time your system comes up, add it as a TBBS ghost
   event with a start time of 23:60.  During normal operation it will do
   it's job very quickly.  This is the BEST way to do it and makes it
   unnecessary to place it on a menu.  Just make sure that a GHOST line
   is available for it to use and remember that TBBS only makes GHOST
   lines available at the top of each minute after initial startup.  For
   example: If you have 3 GHOST events trying to get to one line, and
   each GHOST only takes 1 second to run, it will take 3 MINUTES for all
   the GHOST events to actually be launched by TBBS, Not 3 SECONDS. With
   this in mind, it is a good idea to make sure that FAMGHOST is the
   first GHOST event in the queue since until it runs, users will not be
   able to log on to your system.


FASTACCT.TPG

Each time a user purchases a service either by check or credit card, an
entry is made into the deposit register. You are able to view all new
purchases, see their total dollar value, and expand the information
concerning the purchase.  This expanded information includes the user's
name, telephone number, etc. as well as the credit card info, if a
credit card was used. Once the transaction is verified (you received the
check or called the bank), you may press <V>erify, which will remove the
item from the screen and subtract the appropriate amount from the
Balance owed display.  The transaction is still stored and may be seen
again by going directly into Deposits <C> on the main accounting menu.
These deposit transactions may be periodically aged by configuring the
check/deposit aging in the system configuration menu.  These functions
are duplicated in the FAMSYSOP module in the accounting section.  This
allows you to see new purchases, however, as soon as you log on.

   Entry: New Purchases
   Priv = 255
   Key = ^@
   Type = 200
   Opt Data = C:\FAMOUS\FASTACCT /Q


FASTOWED.TPG

This module may be placed on a menu or used as an autoexecute.
Functionally, it is identical to the balance owed register as it will
only show new purchases which have not been marked as PAID.  It will
allow you to do this, and authorize the service at the same time.  It
will only show new cash transactions, not ones that have no dollar value
assigned.  If there are no awaiting transactions, the module will quit
immediately.

This module serves two important purposes.  First it lets you see how
much money you've made since the last time you logged on (If you're
marking items paid at each logon) and secondly it allows co-sysops to
authorize new transactions without giving them access to the main FAMOUS
sysop module.  When used together, FASTACCT and FASTOWED are a powerful
combination. FASTACCT is strictly a service authorizer, whether it's
been marked PAID or not, while FASTOWED is more concerned about your
cash flow.  It is not necessary to use both.  For free systems, you
might just want to use FASTACCT.  For STRICTLY pay systems you might
just want to use FASTOWED.


USERSTAT.TPG

   Also included is USERSTAT.TPG.  This is an optional ANSI-only module
   you can make available to your users which allows them to view the
   latest system statistics generated by AGER or from a Manual Snapshot.
   It includes the same information that the Sysop would see if viewing
   the System Stats, but will only show the most recent Snapshot of the
   system taken.  It has zero impact on your system, as it does no
   searching or computation, just display.  The three displays will show
   a summary of system activity, a bar graph showing total system usage
   vs. time of day, and another bar graph showing average system usage
   over the the history of you call records.

   Entry: <V> View System Statistics
   Priv = 0
   Key = V
   Type = 200
   Opt Data = C:\FAMOUS\UserStat /Q && [-STAT -TIME -AVGTIME]

    Examples:

    Opt Data = C:\FAMOUS\USERSTAT /Q  && -STAT

    or

    Opt Data = C:\FAMOUS\USERSTAT /Q  && -STAT -TIME

    or

    Opt Data = C:\FAMOUS\USERSTAT /Q  && -TIME -AVGTIME

    And any other combination you want.  Or they can be used as separate
    Type 200 menu calls.  If you do not use any switches, all three
    functions will be displayed.


USERVIEW.TPG

This is an optional program for ANSI and non-ANSI users which allows
them to view Top Downloaders, Top Uploaders, Top number of Calls, Top
amount of Time Online and their own personal Stats.  Invisible users are
not displayed. USERVIEW uses 8 BANNER files to display header
information on the display. Four are .ANS files for ANSI users and four
are .TXT files for non-ANSI users. They are named BANNER1.XXX through
BANNER4.XXX and may be customized.

The Opt Data line of the program will accept up to five parameters which
will tell it what information to display.  If all parameters are there,
the program will cycle through the five different displays.  Otherwise
it will only show the ones that have been designated. You must have at
least one of these parameters in the Opt Data line.

   Entry: <L> Look at Top Users
   Priv = 0
   Key = L
   Type = 200
   Opt Data = C:\FAMOUS\USERVIEW /Q && [# of Users] <-DOWN -UP -CALLS -TIME -USER>

   Example:

   Entry: <L> Look at Top 25 Downloaders
   Priv = 0
   Key = L
   Type = 200
   Opt Data = C:\FAMOUS\USERVIEW /Q && 25 -DOWN

   # of Users = The number of users to be displayed.  Must be the first
   parameter. If left out, will default to 19.
   -DOWN = Top Downloaders
   -UP = Top Uploaders
   -CALLS = Top Callers
   -TIME = Top Time Online
   -USER = Shows detailed Personal User Statistics for this user

Note: The stats displayed in USERVIEW are only updated to include new
users after FAMGHOST runs.  Existing users are updated constantly. Since
new users should always have less calls/time/downloads/etc., this should
not be noticeable.  Personal stats are accurate as of this logon.


FAMCOSYS.TPG

    This was specifically designed to allow co-sysops to verify/modify
    user records.  It only allows the co-sysop to view/manage users who
    have a Priv level less than or equal to their own.  It is
    implemented by a standard Type 200 call with up to 2 additional
    parameters. Like: Opt Data = C:\FAMOUS\FAMCOSYS /Q && [-NOCC]
    [-NOPASS]

    An optional switch may be added to the Opt Data line which prevents
    credit card information from being displayed. The switch is -NOCC.
    To use it, you would configure the Opt Data line like:
    Opt Data = C:\FAMOUS\FAMCOSYS /Q && -NOCC

    A second switch may also be added to the Opt Data line which
    prevents the User's Password and alternate password from being
    displayed.  The switch is -NOPASS.  To use it, you would configure
    the Opt Data line like:
    Opt Data = C:\FAMOUS\FAMCOSYS /Q && -NOPASS

    These switches (-NOCC -NOPASS) may be used together.

FAMPASS2.TPG

    At registration your callers may be asked to create a secondary
    password. In the event that they forget their original password they
    can log on to your system as a specific account name (PASSWORD for
    example). FAMOUS will then ask them for their account or user name
    and their secondary password. If they successfully match both they
    will be given their original password and sent back through the
    logon process.  The module is called FAMPASS2 and may be placed in
    one of your utility menus, or in your top menu, where it is only
    available to the special PASSWORD account.  When run, this module
    displays a text file called PASS2.TXT, which may be modified by you,
    before prompting the user for their primary name and secondary
    password.

    Sometimes people will remember their primary password just by going
    through the routine of being prompted for a password.  FAMPASS2
    takes this into account and will recognize either the primary
    password or the secondary password.  FAMPASS2 is called via a
    standard type 200 command. like:
    Opt Data = C:\FAMOUS\FAMPASS2 /Q  && [-LOGOFF] [-MSG]

    The optional -LOGOFF switch tells the program to logoff the user
    after 3 unsuccessful attempts.

    The optional -MSG switch lets the user send a message to the Sysop
    on the Email board defined in the FAMOUS configuration.

    The call to FAMPASS2 should be on your TOP menu (0000) since the
    Type 43 relogon command which is invoked will leave the user on the
    menu from which FAMPASS2 was called.  By placing it on your top
    menu, the user will be forced to go through your normal logon
    sequence as if they had just dialed into your system.
    Alternately, you could have an autoexecuting Type 45 after FAMPASS2
    which transfers control to Menu0000.

    You should also add a note to the initial signon message advising
    users of your special password account. If you do not want to use
    this feature, simply leave the field blank in the System
    Config/Customize Registration Fields and Prompts area and the user
    will not be prompted for it.  This feature will not be active until
    this prompt is added.

    A word of caution about this feature. By using it, you may be
    compromising some of your TBBS security since anyone can enter a
    name and then try multiple passwords, just as if they were logging
    on to your system.

Other TPGs

   You may notice that there are several other TPGs included with
   FAMOUS.  They must all reside in the FAMOUS subdirectory and are
   called by the FAMSYSOP module.  They do not require you to do
   anything else, i.e. you DO NOT have to put them on menus.  However,
   you may if you wish.  For example, if you want your users to be able
   to view your line statistics, ANSI only, you could put LINEUSE.TPG as
   a menu item.  No other parameters are required.  Or, if you wanted a
   co-sysop to manage your accounting functions, but not be able to get
   to the other functions in FAMSYSOP, you could put ACCOUNT.TPG as a
   standalone menu item.  The same applies for SERVICE.TPG, if you want
   a co-Sysop to manage your Service offerings or STAT.TPG if you want
   co-Sysops to be able to view your Statistics.

Banner Files

All of the user executable files display large font banners in ANSI or a
line of text in ascii, which identify the program's function to the
user.  FAMOUS comes with 12 of these files, 6 are .ANS and 6 are .TXT,
named BANNER1 through BANNER6.  These files may be customized by you for
your system.


FAMOUS Concepts and Overview

FAMOUS is a complete User Registration, Management and Services System
that embodies concepts which are revolutionary to the TBBS world. It is
designed to be as automatic as possible in nearly every respect, from
User Upgrading/Downgrading to invoice and report printing.  For a better
understanding of some of FAMOUS' capabilities, please read on.

Logon Registration - Whenever a new user logs on to your system, FAMOUS
will present the user with a registration screen for them to fill out.
You may modify this screen, and make specific fields mandatory/optional

User Services - FAMOUS allows you to package and sell Services to your
users.  A Service may be a file, flag/priv upgrading, billing class
time, Net Mail Credits, etc.  Services may be bundled together, i.e.
100 NetMail Credits and 20 additional minutes per day of additional
online time or they may be sold individually, i.e. an additional 500K
bytes per day added to their download limit.  You can even specify a
service to run any TBBS command.

Services have the ability to cascade to each other after an expiration
time that you define or they may provide just a 1 time change to the
user's attributes.

Services may be defined as being 'Gifts'.  This allows one user to buy a
service for someone else.

Services may even be set to delete the user from the User databases
as well as the TBBS USERLOG.BBS on his next logon/logoff.

Services may be provided for free, sold for a price, or be automatically
invoked after a certain number of logons.  You may also set up a default
service which is automatically invoked on a new user logon and an
Expiration service which is automatically invoked when a user's
expiration date has expired.

Payment for services which are sold may be made by check or VISA,
MasterCard, American Express, Optima, Discover, Diner's Club or Carte
Blanche credit cards.  Credit Card numbers and expiration dates are
always validated and you define what types of payment you will accept.

You may define, on a service by service basis, what forms of payment
will be accepted.  You may also use a master switch in the system
configuration to determine what the entire system will accept.

Services may also be Forced or Removed for a particular user by the
Sysop.

Sales tax may be added to any service automatically.

Services may be authorized immediately/automatically, depending on
payment type or a waiting period may take effect, allowing you to check
a user's credit before the service actually begins.  The waiting period
may be set to automatically expire after X days from the purchase or it
may last up to 999 days or until the service is authorized by the Sysop.
After the waiting period expires, even if it has not been authorized,
the service is automatically given to the user on his next logon.

In a Service definition you have the ability to charge a flat rate for
billing class time OR set up a per minute fee and let the user decide
how much time he/she wants to buy.  To do this, set up the service as
you normally would for a billing class time sale, but instead of putting
in the actual Billing hours and minutes, put in the fee you will charge
per minute.  Also, leave the Price of the service blank.  If a user
purchases this service he will be prompted for the amount of time he
wishes to buy, allotted that time and billed accordingly.  If
appropriate, sales tax will also be computed according to what he has
purchased.

If you use this function there are 3 rules which must be followed:

1. This service cannot be forced.  It must be purchased through
   FAMBUYER by the user.

2. It must be enabled immediately.  You cannot use the Authorize
   Days. So you *might* want to limit it to credit card users.

3. It cannot be a Gift Service.


User Management - FAMOUS allows you to track and modify most TBBS user
attributes including Flags and Privs, Time/Call/Download limits, Netmail
Credits, Billing class time, etc.  It is constantly gathering a wealth
of statistics which may be displayed and reported on. Users may be
searched based on their names, city, phone number, etc.  Mail may be
sent to a user from within a user's record and all information pertaining
to each user, from his last logon line and speed to the last mailing he
received, is kept within each user record.  User status, flags, etc. are
updated each time a user logs on or off your system.  You may also
instruct FAMOUS to force each user to review/update his profile every X
Days from the last update to insure current information.


RIP Detection - FAMOUS has automatic RIP detection, which you may turn
on/off.  When RIP is detected for any user logging on, you may instruct
FAMOUS to set/reset any combination of A(x) flags.  You may also instruct
FAMOUS to look at a flag which has been set by another program that has
already done the RIP detection.

If RIP is detected when a user logs on, the file FAMUSER.RIP will be
displayed. This is a RIP template file which will allow a RIP user to
either use his keyboard or a mouse to enter data.  This template is
organized as an ANSI window and a mouseable keyboard.  If the file
FAMUSER.RIP is not present in your FAMOUS directory, ANSI will continue
to be used for RIP users.  If it is present, the template will continue
to be displayed to the user throughout his online session unless a
specific RIP clear command is issued. This template is used anytime a
RIP user logs on, or if a RIP user is revising his profile.  Naturally,
if you want to get fancy, you can design your own RIP template and use
it instead of the supplied RIP files, and include various buttons, etc.
The file FAMUSER.RIP was generated specifically for FAMOUS by Randy
Harris and may not be used for any other purpose or distributed. If you
would like to contact Randy for any custom graphics work, he may be
reached by voice at 508-877-5433. For more information on RIP, see the
bottom of this file.


Reporting - FAMOUS has the ability to generate a wide variety of
reports based on User attributes, Services and their sales, or system
usage.  These reports may be sent to your screen, a disk file, or the
printer of your choice.  There are 2 forms of report writers in FAMOUS.
An online report writer which prints reports while your system is
active and a sophisticated offline report writer which allows you to
specify print jobs during the day which may then be printed while your
system is offline.  While the format of the online printing is
pre-defined, the offline Printing may be done with forms that you
design.  And any data field that is contained in a user's record may be
contained in the report and even totalled or separated by group.


Labels - As with the Report writers, the label writers allow you to
print labels online or to specify label print jobs which may be printed
offline.  For offline printing, separate printers may be specified for
Labels and invoices/reports.  And labels may be 1,2,3 across or Cheshire
styles. As with the offline report writer, you have complete control
over the information on each label. User information may also be output
to a DBF file and a comma delimited file for import into a word
processing program or spreadsheet.


Accounting Functions - FAMOUS has comprehensive accounting functions
which allow you to generate invoices and track billing.  FAMOUS accepts
multiple payment types on a transaction by transaction basis.  So a user
might use his VISA to pay for one service and a Diner's Club to pay for
another.  FAMOUS also incorporates an automatic balancing Check/Deposit
register.  Line item invoices may be printed online or during a nightly
event.  Output may be directed to a printer or disk file.  When invoices
are printed during a nightly even by AGER, they are automatically marked
as 'Processed'.  This removes the service from the Active area and
stores them into the Aged Services Database.  When printing from the
online sysop module, you have the option to mark them processed or not.
This allows you to print out test invoice or duplicates without
disrupting the normal processing cycle.

You may also manage the stored invoices from the Accounting module.
These functions allow you to View, Delete or Rolloff via age your hard
copy invoices which are stored in the INVOICES subdirectory.


System Statistics and Line Usage - FAMOUS constantly gathers and
processes statistical information which may be used to monitor your
system's usage.  These include a variety of reports which allow you to
see line usage, line usage by speed, line loading, line usage by time of
day and many, many more.


Aging - FAMOUS automatically ages, based on parameters that you set, the
user databases, call information databases, and the services databases.
Aged/Expired/Deleted users are automatically placed in a separate
database where they may be retrieved later and reinserted into the
Active Database.  All online reports and searching may be run on the
information in the aged databases as well as the active databases.
Services are aged as well and also kept in a separate Aged Database.
This database may also be reported on and searched.

Aging is a critical item as it allows you to manage the amount of disk
space that FAMOUS will use.  You should view aging as a way to have
FAMOUS clean it's own house every X days that you define.  If the house
gets dirtier quicker, clean it more often.  Set the aging times that are
right for you're system.  Busier systems may want to age more often, low
volume systems can age less often.

Mailing history - FAMOUS maintains a rolling list of the last 10
mailings that were sent to each user on a user by user basis.
Furthermore, when a new user logs on, you can have FAMOUS interrogate
him and check if he is responding to a mailing.  If so, pre-loaded
information will be automatically displayed for verification and a
mailing code will be added to his user record, identifying which mailing
the user responded to.

Console Alert Messages - FAMOUS is able to send messages directly to
your TBBS Console as important events occur, even if you are logged on
to it at the time. The messages will contain the type of event as well
as the user's name who is responsible for it. Console Messages will be
sent for the following events:

   A. A user has just purchased a pay service
   B. There has been a trash can violation
   C. A new user has just entered your system and registered
   D. A transaction has just been attempted with a bad credit card.

ANSI.SYS MUST be installed in your CONFIG.SYS file or this will not
operate properly. Therefore, in your Config.Sys file, you must have a
line equivalent to: Device=C:\DOS\ANSI.SYS

These messages will remain on the 25th line of the console until either
the screen blanks, you move from console mode to logon mode and back, or
you press an FKey which uses this line to display information (Like
Killing a line or taking a dump).  As new messages are received, they
will overwrite old messages.  To Enable/Disable this feature, a switch
is located in the first screen of the System Configuration.

These are some of the basic capabilities of FAMOUS, but there are many
more that you will soon discover as you begin to use the system.


Configuring FAMOUS

After you have installed the software, logon to your system and run the
FAMOUS management program, FAMSYSOP.  As you logon for the first time, you
may receive a file not found error message from FAMFAST.  This will be
remedied as soon as FAMSYSOP is run and the Index files are
automatically built.

The first thing you will want to do is to modify your FAMOUS
configuration.  Press <5> from the main menu and <1> from the
Configuration Menu.

Email Board is a board defined in CEDIT where mail will be sent when you
send mail to a user from within his record.  It is upper/lower case
sensitive and must be spelled correctly.

BBS lines for reports is the number of lines that you have on your
system and want FAMOUS to report on.

Send Alerts to Console turns On/Off the console alert feature

RIP Check will Poll the user's terminal emulator and determine if he is
using a RIP-capable terminal emulator.  If he is, the flags that you
have defined will be set in his user record. Options are (-), (.), (X).
Also, if RIP is detected and RIP Check is on, the user's ANSI flag in
the userlog will automatically be turned on.  This is a necessary step
for the TBBS implementation of RIP.

Display RIP if Flag lets you use a flag that another program has set
that determines if a user has RIP or not.

Set A(x) if Age allows you to set any flag depending on the user's age as
determined by the birthday they have entered.

Turn on a New User's Active Flag turns the user's Active flag on in
his user record.  The Active flag is used to keep users from being Aged
to the Aged User Database, regardless of the condition of the expiration
date.  It may be overridden by manually deleting a user or changing the
Flag to N.

Display Mail List Interrogation further prompts a new user and checks to
see if information for him has been pre-loaded into the user database.
If it has, it is displayed and the user is asked to edit/review it.  If
you are not looking for new users to respond to mailings, this option
should be turned off.

New user display is the name of a text file that is displayed to all new
users prior to the registration screen.  It may contain insertion
parameters.

New User Default service is the code of a service you wish users to have
assigned when they first logon.

Expiration Service is the service which will be invoked when a user
expires.  This will be in addition to any other services you have
designated the primary service to cascade to.  In many applications,
cascading will not be necessary as the Default expiration service will
provide the means necessary to downgrade user capabilities on
their next logon AFTER they have expired.  If you want to display a
message to users prior to expiration, you do no need to use a service to
do it.  See Expiration Messages for more information.

Have users check info is the number of days from the last time that
their user record was updated when you want them to re-verify their
registration info. A normal setting might be 6 months, 180 days.

Display File on Info check is a text file that will be displayed prior
to the user having to re-verify their profile.  Insertion parameters are
allowed.

Display File on Trash check is a text file that will be displayed when a
user has entered information on the registration screen which is also
contained in the Trash Can.  This file will be displayed before the user
is logged off.  Insertion parameters are allowed.

Display File on Birthday is a file that will be displayed when a user
logs on on his birthday, if you are requesting Birthday information in
the user registration.

Online print on LPT1-4 is the printer where FAMOUS output is to be
directed.

Name to appear on Invoices is the name of your BBS that will appear at
the top of all printed invoices.

Payment types accepted is the type of payments you will accept when
services are purchased.

Characters for $ is a 2 character field which allows you to specify the
characters users will see when they purchase services.  In the U.S. this
would usually be $, in Germany DM, etc.

Sales Tax is a master setting for your sales tax collection.  Enter the
% amount that you will collect and the applicable state you will collect
from.  If you want to collect from all users, enter XX as the state.
This is also specified and may be overridden in each service definition.

Date type is the type of date format your system uses.

Now press <2> to instruct FAMOUS on how to Age it's databases:

Nightly Event Database Maintenance:

You may specify the frequency of aging for the main databases.

For the Userlog, users are aged X days after their expiration date has
passed, if their ACTIVE flag is set to 'N', and are put into the aged
database.  Any user that has been deleted from the active database is
put into the aged database every time AGER is run.

The information about Userlog synchronization has been explained earlier
in this doc. More detailed information is also presented at the end.

You may also instruct to permanently delete users from the Aged database
n days after their last logon.  This allows you to 'stage' the aging
process so that they are first moved into the Aged database n days after
they expire and then permanently removed from the aged database n days
after their last call.

For Services, aged services are aged and put into the aged database
whenever they have expired or have been deleted.

For Call info, Call statistics are aged every X days after the call.

Aging checks and deposits removes them from the registers n days after
the transaction

Packing Databases can be done every X days or never.


Now Press <3> to configure off line printing:

Nightly Event Printing:

For offline printing, determine which printer(s) will be used for label
and report writing or if the output is to be sent to a disk file.

Also determine if you want reports, invoices and/or stats printed during
the nightly event.

If you decide to do nightly printing to a printer, make sure that the
printer is turned on and connected.


The next area to configure is online printing.

First we will look at the Label Configuration.  From the Main Menu,
press <3>, then press <8>.  These are the parameters that will be used
when printing online labels:

Label width is the maximum amount of data the label can hold
horizontally.

Top Margin is how many lines from the top of a page of labels do you
want to space.

Left Margin is how many spaces from the left side of the page do you
want to space.

Lines between Labels is the spacing between each label on the page.

Labels down the page is how many labels to print before an eject is
issued to the printer.  A value of 0 will print labels continuously
without an eject.

The next area to configure is for Invoice Printing:

From the main menu, press <A>, then <2>, and finally <3>.

Address lines will appear on the right side of the invoice and are
typically the name/address that you want payments remitted to.


The header that you define will appear directly above the first invoice
item.

After you complete these definitions, you should press <4> from the
INVOICING menu to disable processing and print an invoice out for a user
as a test.  If your printer is off or disabled, the invoice will only be
printed to the screen.

The second phase of configuring the system is to develop/modify report
forms and label forms for the offline label/report writers.  Each
definition you create can be specified in a print job so that you can
have reports/labels with different information in them.  This is more
important for reports than labels.  You define offline labels and
reports using FAMRL.EXE.  More on this utility later.

You will also want to configure the registration prompts that your
users will see. You are able to change the wording of any of the fields
that the user will see.  If you leave a field blank, that information
will not be requested at all.  You may also make a field mandatory or
optional for the user to fill in.  All fields are character oriented and
will accept any information EXCEPT for the Birthday field, which will
only accept a Date, and the Phone number fields which will follow the
rules of the mask you define.

The phone number mask allows you to format the field for the input of a
phone number.  DO NOT LEAVE IT BLANK!  If you want free text formatting,
place all X's in the Mask.  Simply put, the mask will only allow the
user to modify a character position that is occupied either by an X or a
9. An X will allow the input of any alphanumeric character, a 9 will
only allow a digit to be entered.  Any other character will be displayed
and will not be modifiable, including a space.  For example, a mask of
[phone] will display the parenthesis, the space between the area
code and the prefix, and the - between the prefix and the extension.  It
will force the user to enter an area code.  If you didn't want to force
the area code you could make the mask (XXX) 999-9999.  This would allow
the area code to be blank, but force the user to enter digits for the
rest of the field.

The alternate password field is special.  If it is used, the user may
retrieve his primary password, if forgotten, by accessing the forgotten
password module, entering his normal logon name, and then entering his
alternate password.

Finally, you should configure the registration questions that your users
will be asked.  This is invoked from the System Config menu <7>.  You
may change any category name, and enter any number of questions, up to
10, per category.  You may also make each question mandatory or
optional.


Using FAMOUS

FAMOUS was designed to be relatively easy to use and intuitive as well
as extremely powerful and flexible.  With this in mind, the main
functions will be discussed as well as those that AREN'T so intuitive
rather than a detailed description of each and every field.

Expiration Dates and Aging

Users on your system may have expiration dates assigned to them  via a
service which may be purchased, bought or assigned by you.  FAMOUS uses
these dates to determine when a user record should be moved to the aged
database during a nightly event.  The expiration date works in
conjunction with the Active flag, i.e. a User who has his Active flag
set to Y, but has expired, will not be moved to the aged database.  So,
he will not have to re-register.  Furthermore, in the system
configuration, you determine how long an expired user will remain in the
active database prior to the active flag being checked.  For example, if
a user expired 20 days ago, you have the active flag = N, but aging is
set for 30, he will not be aged.  Via Service cascading you may have
lowered his privilege levels, but he will not be Aged.  On the 30th day
after he has expired, however, he will be aged and will have to
re-register as a new user to gain access to your system unless the
ACTIVE flag still = "Y". The state of the Active flag may be changed at
any time, either manually or via a Service.  Users who show as deleted
are automatically move to the Aged database regardless of their
expiration date or ACTIVE flag.

Expiration Messages

FAMOUS has the ability to display different expiration messages,
depending on the number of days a user has left before he expires.  This
is done automatically and no configuration options need to be set.  All
you need to do is to create files named 'EXP' + <number of days till
expiration> + '.TXT'.  For example, the file EXP10.TXT will be displayed
to a user if he has 10 days left till he expires, EXP5.TXT will be
displayed to a user if he has 5 days left till he expires, EXP4.TXT will
be displayed to a user if he has 4 days left till he expires, and so on.
There is no limit to the number of expiration display files you may
have, and they may trigger on any date. Only the file that exactly
matches the number of days left, however, will be displayed.

Renewals

If a user renews a subscription, depending on how you define the
service, the length of the subscription will be added to the existing
expiration date.  You may also configure the expiration date so that it
is reset to the service purchase date plus n days.  So, if a user has a
6 month subscription and has only used 5 months of it and then renews
for a another 6 months.  He will wind up with a 7 month subscription.
Or, using the second method, he could be set to start just a 6 month
subscription beginning at the purchase date. By using the PRIV windows
within the services and the service length, you can extend a user's
expiration date to reflect 7 months before expiration, yet only give him
6 months of the new service.

Service Lengths and Cascading

Each Service that you define can be invoked as a one time event, a new
user logon, for example, or be set to last for a set period of time and
then invoke another service.  For example, let's say that you have a 6
month subscription service.  After 5 1/2 months you want to remind users
that their service will expire soon.  After 6 months and one day, you
wish to revert them to a lesser privilege level.  Finally, after 7
months you wish to delete them from your system entirely.  You would set
up services as follows:

    1. A 5 1/2 month subscription service which provides for the additional
    capabilities you desire.  At the end of which, it invokes:

    2. A simple service which does not change the user's settings but
    displays a file telling them that their subscription will expire
    soon.  It, in turn, invokes another service, after 2 weeks or X
    logons, that reverts the user back to a New User level.  Finally,
    one month later, the last service is invoked which:

    3. Deletes the user from the Active Database and TBBS userlog, set
    his active flag to N, which means he will now be aged,lowers his
    priv levels, or just displays a final file the next time he logs on.

    You'll need to take some time and think about it <grin>. Since you
    aren't forced into any particular course of action by FAMOUS, it
    will do exactly what you tell it to do.

    A simpler way to accomplish this same task would be to NOT use any
    cascading and let FAMOUS do it for you with it's automatic cascade
    to the expiration service.  In this case, the service length on the
    subscription service would be set to 0, the Go to Code field would
    be left blank, and the expiration date would be the key element used
    by the system to trigger events.  As the user got closer to his
    expiration date, FAMOUS would automatically begin displaying the
    EXPn.TXT files. Finally, when the expiration date had passed, FAMOUS
    would automatically assign the automatic Expiration Service that you
    had defined.


Service PRIV Windows

Each Service may be configured with a privilege window that only allows
users within the window to purchase that service.  For example, if you
have a user with a Priv of 50, you wouldn't want him to purchase a
service which would downgrade him to a Priv of 30.  The window has an
upper and lower threshold, and only users within the window will be
assigned that service,


Services that delete other Services

A service is also able to override and delete any other services which
are waiting to cascade.  For example, let's say you have a new user
service, DEF, which gives a new caller access for 3 days.  On the second
day, this user buys a membership service.  This membership service is
now able to delete the DEF service before it can activate.


Service Information Files

FAMBUYER has the ability to display a different text file for each
service as <M>ore Info.  This file would typically explain what the
service does for the user and why he should purchase it.  This file is
defined in the Sysop Service definition area and may be unique for each
service.


Service Lengths and Expiration Dates

These two items are completely independent from each other, or may be
set to coincide.  At the end of a service length, that service will
expire and be aged.  Unless another service is set to Go to,
however, nothing else will occur. If you just want a user to expire at
the end of a time period, with no change in his Active flag, or anything
else, it is not necessary to set a Service length.  Just set the new
expiration date/days to the desired date/number.


Expiring services which aren't Picked up

In the Service Definiton there is a field which allows you to specify
how long the service will wait for the user before it disappears.  Let's
say you assign a service to a user, and he never logs in again to pick
it up.  That service could hang around in the database forever. You
can put a time limit on it so that after X days, if it hasn't been
picked up yet, it will be aged and AGER will delete it.


Forcing Services

The Sysop may force a service on any user or on any group of users based
on Priv Level.  Both are accomplished through the user information
system.  Forcing a service on a group can serve many purposes, such as
upgrading/downgrading them or just displaying a bulletin.  Forcing a
service on an individual user is accomplished when viewing the second
screen of an individual user's information record. The service that is
forced will not take effect until the next time the user(s) logs on or,
if he is online when the service is forced, when he logs off.

TABS Support
The way this works is as follows.  In your SDL, you would put the
TABS program immediately following FAMFAST.  It would be protected
by a flag so that only unregistered users would hit it.  After
filling out their FAMOUS registration screen, the TABS module would
be invoked as an autoexecute.  If they entered the correct ID
number, the TABS module would be configured to trip a flag.
Following the TABS module, you would put FAMTABS, protected by the
flag that TABS just tripped. This flag says that TABS has detected a
user who paid for the TABS service and is authorized.  In the
FAMTABS Opt Data line, you would put the name of the service to be
invoked.  Like: Opt Data=C:\FAMOUS\FAMTABS /Q && TAB

FAMTABS will then run and provide the user with that service.  So
the whole thing would look like this:

Menu:0000
Entry: Famous Logon
Key=^@
Type=200
Priv=0
Opt Data=C:\FAMOUS\FamFast /Q && %BPS%   -%Loggedon%


Entry: Go to real top menu for existing TABS users
Key=^@
A1=X......X
Priv=0
Type=35
Opt Data=TOP

Entry: TABS
Key=^@
Type=200
A1=X.......
Priv=0
Opt Data=C:\TABS\TABS /Q

Entry: FAMTABS
Key=^@
Type=200
A1=X......X
Priv=0
Opt Data=C:\FAMOUS\FAMTABS /Q && TAB

Entry: Go to real top menu
Key=^@
Type=35
Priv=0
Opt Data=TOP

EndMenu:

In this example, TABS is tripping A1(8) to indicate that the user
has provided a correct TABS ID number.  That, in turn, allows
FAMTABS to execute and provides him with the appropriate service.
In this case, the service named TAB.

Notice the 2 Type 35s.  The first one will trip for someone who has
already passed through the TABS program successfully.  If not, they
will be sent through the TABS module again.

Instead of an autoexecute, or in addition to it, you could also
place the TABS/FAMTABS combination in a menu, using TABS as a menu
pick for manual registration, followed by FAMTABS as an autoexecute.
This would let existing users access it as well as new users.

A third method would be to include the TABS program as part of your
Default Logon Service for new users instead of the autoexecuting
TABS entry.  This would still require FAMTABS as an autoexecute,
however.

The Trash Can

The Trash Can is a way for you to weed out bad credit cards, telephone
numbers, Names, words or phrases.  When a user registers, the
information he enters is checked for any word/phrase that is in the
Trash Can and is contained in his logon name, real name, street, city,
state, or Zip. The same applies to phone numbers. If there is a match, a
file will be displayed, as defined in the system configuration, and the
user will be immediately logged off.  Note that this is a 'Contains'
search.  So, if you put JERK in the trashcan, a match will be made on
Joe Jerk or on Joe Myjerkowski.

It is also possible to more selectively trap 976 or 900 phone
numbers (or anything else).  This will usually require 2 entries.
This is made possible by entering a ~ after the number. Like 976~.
What this does is to force the search to look for a space after the
976. This would find numbers like '976 1234'. You could then add a
second trash can entry like 976- which would search for numbers like
'976-1234'.

This new feature lets you find these numbers WITHOUT finding
embedded numbers like '267-1976' (note that 976 in 267-1976 is not
followed by a space or preceeded by a dash and therefore wouldn't be
trashed). This feature will work for any of the phone number entry
fields.

Credit card checking is only done when a user attempts to purchase a
service.  If a match is made between the Trash Can and a credit card
number that the user has entered, a message is displayed that the system
does not accept that credit card and the purchase is cancelled.  The
user is not logged off the system.  A log file is kept of all credit
card purchases that fail, whether by a bad card number, expired card
date, or if a card was found in the Trash Can.


Credit Card Verification QAL

The actual Credit Card checking is done via a QAL, CREDIT.QAL.  You may
configure this QAL to display additional information, and modify the
type of credit cards that your system will accept. (See the QAL section
of your TBBS manual for more info).  DO NOT MODIFY ANY OF THE PUTSVY
STATEMENTS AND DO NOT ADD ANYTHING THAT WILL BE WRITTEN TO THE .SVY
FILE.  THE ONLY THINGS THAT ARE PERMISSIBLE TO MODIFY IN THE QAL IS
DISPLAY INFORMATION AND CREDIT CARD TYPES.  Following any modification,
you will need to recompile the QAL.  The resulting QAF must always be
named CREDIT.QAF and reside in the FAMOUS directory.

The following statement in the QAL should be modified to reflect what
type of credit cards will be accepted.  The CARD= statement tells the
QAL which cards to accept.  For example, if CARD=VM, then you will only
accept Visa and MasterCard.

VAR = C Type=CARD CARD=VMADBC NAME=A ERROR=Badcc


Info Checking

You have the ability to force a user to review his registration
information every X days.  This is configured in the System
Configuration menu, as is a text file that will be displayed prior to
the registration screen appearing.  Typically, you might want to set
this for 180 days, 6 months.  When it is reviewed, the last updated date
in his information will be updated.  You may also force this to happen
by setting the Force Revise flag in a user's record or through Tagging
functions.


Mail Codes

You have the ability to assign codes into a user's record.  This is
accomplished through tagging functions or by manually editing a user's
record.  With Tagging, you can assign a specific code to all TAGGED
users or have the system generate semi random codes which are unique for
all TAGGED users.

Once codes are assigned, they can be printed/output through the online mailing
label generator.

Next, you create a Registration service.  If you are using a code which
is the same for all users, enter that code and point it at a service.
If you are letting the system generate semi-random codes, enter the word
RANDOM as the Access ID, and point it at a service.  You can do both at
the same time and have as many Group Codes as you want.  There can only
be one RANDOM code, however, and it may only be used for this function.
RANDOM is a reserved word.

Install the program GIFT.TPG as an autoexecute PRIOR to FAMFAST in your
logon routine in menu0000.

How it works:

GIFT will check the user's record to see if there is a code in his Mail
Code field.  If there is, it will display a text file called Gift.Txt
and request the user's Mail Code.

When the user enters the code, Gift will first check to see if there is
an Access ID code with that designation.  If there is, it will be queued
for delivery, which will occur as the user passes through FAMFAST.

If there is no Registration service with that code, GIFT will compare it
to the code in the user's record.  If there is a match, the registration
ID RANDOM will be applied.  Again, you can only have one ID named RANDOM.

Once either has been applied, the mail code will be removed from the
user's record so that GIFT will be skipped over on the next logon.

GIFT is an extremely FAST autoexecute and will integrate seamlessly with
the rest of your system and with FAMOUS.

Note that GIFT will only work with users who have already registered
with FAMOUS.

GIFT-assigned services are not pay services and will not generate
deposit tickets.  They are always free.  Other than that, however, they
have the full suite of Service capabilities.

This new feature has several uses:

1. A way to distribute unique codes to new users via mailings so that
   only they have access to your system.

2. A way to distribute unique codes to users via mailings in the form of
   a gift certificate that they may redeem when they logon to your
   system with the proper code, i.e. a service that gives them more time
   on line, more download bytes, etc.

3. A way to allow previously registered users to become part of a 'Group
   Registration ID' without purchasing a service.


User Questionnaire

You may define up to 8 user categories, and define up to 10 unique
registration questions within each category.  This is selected from the
Main Sysop menu.  The first letter of each category MUST be unique, i.e.
Sysops, New Users, Old Timers, Froody Dudes is OK, but Sysops, Surgeons,
Lawyers, Other is not because Sysops and Surgeons both begin with 'S'.
Of course, the first 'letter' could always be a number like 1 Sysops, 2
Surgeons, etc.

If all the Question fields in a category are left blank, no further
questions will be asked.  Otherwise, the user will be prompted to answer
Registration questions.  User Answers to Questions may be viewed by
going to the third screen of a user's record, using the <M>ore key.
Answers may also be reported/printed from the Database Searching area.

Statistics and Demographics

FAMOUS captures and analyzes a wealth of statistics.  They are all self
explanatory, but it is important to note that FAMOUS will not
incorporate line usage statistics for any user with a PRIV = 255.  This
is to insure that the stats fairly represent the activity of your user
base.....Not you.  Statistics are available in two places: From the
Main Menu <6> and from the Main Menu <4>.  The difference between the
two is that <6> will give you an overall system summary of your users
and their activity while <4> will process and display data aimed more at
communications and line activity.

Whenever AGER runs, it will do the brute force work of gathering System
statistics from the various databases, processing them, and storing them
in the EVESTAT database.  You also have a choice in FAMSYSOP whether you
wish to view the statistics that are gathered in realtime or the ones
that were gathered by AGER during it's last run.  Since these stats are
very general in nature, and not too time sensitive, looking at
AGER-gathered stats can give you a fairly good view of your system.  If
you do decide to view the realtime stats, you may take a snapshot of
them, which will then be saved to the stat database where they may be
viewed later.  This database will store up to 31 snapshots taken
manually or by AGER.  When more than 31 are stored, the oldest will be
automatically deleted, and the database packed, when AGER runs.  This
allows you to keep a month's worth of Stats at a time.

The reason for adding this capability is simple.  Gathering these stats
and processing them is a very CPU/Disk intensive process and can take a
long time in an online environment.  By letting AGER do the work during
an offline event, or taking a Snapshot from the realtime stat
gathering, you keep your online performance high and can view the Stats
very quickly as well as browse through them. Please note that these are
the stats accessible from the main FAMOUS menu by pressing <6> System
Statistics.

Whenever AGER runs, it also produces a demographic report by Zip Code,
City, State and Country.  This report shows the number of users in each
category as well as the percentage of your total user base, number of
active users, inactive users and renewals.  It is in a text file called
DEMOGRAF.INX which may be printed or downloaded.  It may also be Browsed
from within FAMOUS in the Database Searching Menu and even searched on.
This is great stuff if you REALLY want to know where your user
population is coming from and if they're subscribing or renewing.

AGER will also produce a list of all your users, sorted in descending
order by age.  This file is AGES.TXT.

At the end of this report, a summary of user ages is presented which
will show you the average age, by age group, of your user population.
This file is AGESUM.TXT


Registration Prompts

You have the ability to Change/Modify/Not use the meaning of any field
on the New User registration screen.  In the configuration section,
select the appropriate entry.  To omit a field leave it blank, otherwise
accept it or change the field Name.  It will also be changed when the
Sysop views a user's individual information.  You may select it to be a
Mandatory Field or Optional. If you mark it as Mandatory, the user MUST
make an entry into it.  You may also modify the phone number mask.  In
the USA you would normally use [phone].  In Canada you might use
(XXX) 999-9999, thus not requiring that a 3 digit area code be entered.
In Europe it might be all X's, so that any number of any length might be
entered.  Regardless of what you choose, something must be entered into
the mask. X's will accept any character, 9's accept only digits 0-9, and
any other character entered will be non-modifiable, such as a '(' or
even a space.

In addition, you may elect to omit the large font banners in both the
registration and service screens, and you may have the registration
screen ask the user for information one line at a time (for ANSI users),
instead of displaying the entire screen at one time.  Many Users/Sysops
prefer this style.  You may also modify most prompts which are displayed on
the Registration Screen.

Registration ID's

You may specify that a Registration ID be asked at new user
registration.  This ID, if entered correctly, can then invoke a
specified service which is then applied to the user.  Registration IDs
are specified on the Configuration Menu.  You will note that the term
'Access ID' is sometimes used instead of 'Registration ID'.  They refer
to the same thing.

Re-indexing Databases

FAMOUS uses an extensive number of index files (.NDX).  This allows it
to search rapidly for information as well as arrange the order in which
it is presented.  It is possible for index files to get out of synch
with the main databases....when a system crashes, for example.  When
this happens you may encounter error messages such as 'Record not found
in Index', 'End of File hit', etc.  At this point you must rebuild the
NDX files to get things back in synch.

Databases may be indexed in a number of ways.

  1. By deleting all .NDX files in the FAMOUS directory, they will be
  automatically rebuilt the next time the Sysop program, FAMSYSOP, is
  run.

  2. Manually, on the Sysop menu.  Since online indexing may only be
  done when there are no users currently accessing the databases, FAMOUS
  will grey out this option when you have users Logging on, Logging
  off, or Purchasing Services.  This is NOT foolproof, since a user
  might attempt to logon while the indexing is in progress and will be
  kept from entering your system by FAMOUS until indexing has been
  completed.

  3. Through the module, FAMGHOST, which may be run as a TBBS ghost task
  or from a menu.  If you want it to run as a ghost event, add it via
  CEDIT.  If you want it to start as a ghost and reindex automatically
  every time your system comes up, give it a start time of 23:60.
  Otherwise, set it to begin immediately after your nightly event. While
  FAMGHOST is reindexing, anyone attempting to log on will receive an
  error message.


FAMOUS Mailer Registration

  You may interrogate a new user to find out if they are calling your
  board in response to a mailing you might have sent.  This is a
  powerful tool which lets you track your response rate.  This function
  is designed to work in conjunction with FAMOUS' ability to import
  comma delimited text files in order to pre-load it's user database. It
  works like this....Let's say you just sent out a mailing.  In the
  mailer or on it's label, you also put a mailer response code.  Since
  this mailer was directed at people who aren't current users of your
  system, you also pre-loaded their names, addresses, etc. from a
  comma-delimited text file.  You have also turned on the Mail
  Interrogation in the Configuration section.  A prospect gets the
  mailer and dials your system.  This is what will happen:

  1.  The first thing he will see is the FAMOUS mail interrogation
  screen.  It will prompt him for his real name, his zip code, and the
  mailer response code that you put in the mailer or label.

  2. After he fills in the above items, FAMOUS will try to find a match
  between the pre-loaded information, and the info that the user just
  put in.

  3. FAMOUS will then take the user to the normal registration screen.
  If it found a match, it will display the pre-loaded information (Ansi
  Only) and ask the user to verify/complete it.  Otherwise, a blank
  registration screen will appear and the user will register normally.

  4. If the user enters a valid Mailer response code on the opening
  screen, it will be added into the user's record where it may then be
  reported on.

  If you are not using mailers, this option should be turned off in the
  configuration section as it serves to meaningful purpose.


Tagging Users

 In the User Information Menu you will notice Tagging Functions.  These
 are a very powerful set of commands which allow you to tag user records
 and then perform operations on them or report on them (User Reporting).

 For example, you might want to import a mailing list.  Then, three months
 later, you can TAG all the users with a PRIV = 0, i.e. never logged on,
 and delete them.  They will then be aged out during the nightly event.

 You may also create a TBBS DNL list of tagged users.  This is handy
 for doing a mass mailing for users who are about to expire, or for any
 other reason. This DNL may also be used in conjunction with PostMaster,
 to create broadcasts without using the actual TBBS message base.

 In a similar manner, you may also TAG all users who appear on a DNL
 that you have identified.  This is a VERY powerful feature.

 Tagging is not limited to these functions, and Tags are stored in the
 user's record, until they are untagged by you.  So, you could use
 tagging as a way to mark reviewed users, for example.

 You may also use a Tag Filter in the User Browsing screen which will
 only display users who have been tagged, when it is activated.

 A very powerful feature is to Tag users and then apply a Template to
 them.  This lets you make changes to user parameters which are applied
 to the user on his next logon/logoff/profile revision without the use
 of a service.

Tagging may also be used in combination with AGER to delete users from
both the TBBS Userlog and from FAMOUS.  You would do it like this:

1. In FAMOUS' Tagging functions, tag all the users you want to delete
   who haven't called in n days.

2. Now select the Delete all Tagged Users function.

Ager has the ability to delete users from the TBBS userlog who have also
been marked as deleted in the ACTIVE FAMOUS database AND to delete users
from the FAMOUS database who have been marked deleted with the KEEP flag
off in the Userlog.  To use these features, enter the path to your TBBS
USERLOG.BBS in the System Configuration section of FAMSYSOP.  The path
must end with a trailing "\".  Like C:\TBBS\. This activates the
function. The second step is to decide if you want to force the KEEP
flag off in the userlog for users marked as deleted in the database or
just leave it the way it is. And finally, decide if you want the delete
status of a user record in the Userlog to also force a delete in the
FAMOUS database, when the KEEP flag is off.

When AGER runs it will check to see if the path is there AND if it's
time to pack the databases.  If the path actually points to the
USERLOG.BBS directory, it will find all deleted users in the database
and also mark them as *Deleted* in the TBBS userlog. Depending on the
status of the KEEP flag switch in FAMOUS, it will also either force
their KEEP flag off or leave it alone.

You can also have it look for deleted users in the Userlog and delete
them from the FAMOUS database.  This function will look at the *Deleted*
status of a user record in the userlog and, if his KEEP flag is also
turned off, will delete his record from the FAMOUS database.

When doing this, AGER will keep a log file called $DELUSER.LOG of all
the users it has actually marked as deleted from the TBBS Userlog. This
file may be moved or deleted at any time.  Otherwise it will be appended
to each time this function is used.

The reason I'm keying on the packing date as well as the path is to keep
things in synch between the Userlog and the FAMOUS database to avoid
confusion.  This way, when a FAMOUS user is removed from the active
database, he will also be deleted from the USERLOG.BBS at the same time
when packing occurs and everything will be completely synchronized.

Regardless of the type of delete you choose, FAMOUS->Userlog or
FAMOUS->Userlog and Userlog->FAMOUS, the deletes all occur within a
single pass of the Userlog, so processing time will remain constant no
matter how you choose to do it.

This will be a very handy feature for you.  Besides picking up users you
have manually deleted, or deleted via tagging, it will also get the ones
who were deleted by the Trashcan or who decided to hangup before they
filled out the Logon registration screen. It will also remove users who
do not have their FAMOUS ACTIVE flag on, have past their expiration date
and have past the Userlog aging date (set in the System Configuration).
Also, if you occasionally delete users using ULEDIT, but haven't deleted
them in the FAMOUS database, it will take care of that for you as well.

Remember, users are only MARKED deleted in the TBBS userlog.  To
permanently remove them you will have to age it, using ULEDIT's 'BACKUP'
function or run ULEDIT /U from a batch file.  Deleted users will still
be moved to the FAMOUS aged user database even though they are no longer
present in the TBBS USERLOG.BBS.

The program is also set up so that it CAN NEVER delete record 0 (the
Sysop) from the userlog.  Even if he has been deleted in FAMOUS.

If you do not feel comfortable about AGER working on a live copy of
USERLOG.BBS, add batch commands prior to AGER in your RUNBBS file that
copies USERLOG.BBS to a Backup directory.  Point Ager at that backup
directory, via the System Configuration, and let it process against the
backup copy.  When it is done, overlay the original Userlog with the
copy that AGER worked on.

Here's a sample that could be part of your RUNBBS.BAT file:

   CD C:\TBBS
   MD BACKUP
   COPY USERLOG.BBS  BACKUP
   CD BACKUP
   COPY USERLOG.BBS USERLOG.SAV
   CD C:\FAMOUS
   AGER.EXE //F:60
   CD C:\TBBS\BACKUP
   REPLACE USERLOG.BBS C:\TBBS
   DEL USERLOG.BBS
   CD C:\TBBS
   ULEDIT /U

In this case, I'm making a backup of the userlog in the BACKUP directory
every day before AGER runs, as well as an original copy called
USERLOG.SAV. Then we're processing against the copy and moving it back
to the TBBS directory, overlaying the original USERLOG.BBS, and deleting
the modified copy but retaining a copy of the unmodifed USERLOG for
backup.  Finally, I'm running ULEDIT /U to permanently remove the
deleted users from the Userlog.

The only reason for doing this backup is if you don't trust your power
or your PC.  It is possible that if either burps, while AGER is running,
it will corrupt your Userlog.  Under normal operation this won't happen,
but an ounce of prevention..... As a side note, ULEDIT does the same
thing by creating the USERLOG.BAK file for the same reasons.

So Here's a Summary:

   A. FAMOUS can delete users from the USERLOG.BBS, that are also
      deleted in the database, but not affect their KEEP flag.

   B. FAMOUS can delete users from the USERLOG.BBS, that are also
      deleted in the database, and force their KEEP flag off at the same
      time.

   C. FAMOUS can Scan the Userlog and, if it finds users who are marked
      deleted with their KEEP flag off, will also delete them from the
      FAMOUS database.

   D. Items A or B must be active in order to use item C.  Item C
      requires no additional processing overhead.

   E. Database packing will immediately follow and will cleanup the
      FAMOUS database.  Deleted users will be moved to the Aged User
      Database.  Run ULEDIT /U to remove deleted users, who have their
      KEEP flag off, from USERLOG.BBS.

   F. The switches for these functions are in the FAMOUS System
      Configuration area.  Once configured, the process is completely
      automatic and requires no further attention.  It may also be
      turned off at any time by removing the path name for the
      USERLOG.BBS file from the configuration.

   G. Record 0 in USERLOG.BBS will never be touched.

   H. FAMOUS can be told to NEVER delete a user who has his KEEP flag
      set.

The next time AGER and FAMGHOST run, the deleted users will be removed
from the Active user database and placed in the Aged User Database where
they may later be retrieved or reported on.


Log Files

 FAMOUS builds and maintains 4 text files which are logs.  They may be
 deleted or renamed at any time and they will be automatically rebuilt.
 They are:

 BADCARDS.LOG, a record of all bad credit card transactions.

 TRASH.LOG, a record of users who entered information that was caught by the
 Trash Can.

 FAMBIZ.LOG, a record of all user purchases which have a dollar value,
 i.e. not $00.00, and are not Default Services.  This log contains the
 user's Handle, name, address, etc. as well as the service purchased
 and, if a credit card was used, all the credit card information.

 SERVICE.LOG records each time a service is actually delivered to a user

 FAMOUS has the capability to use an internal scrolling file viewer to
 view all four files.

 $DELUSER.LOG records users who have been deleted from the TBBS
 Userlog.BBS file by Ager.

 A .LOG file is also built each time FAMGHOST is run, called $INDEX.LOG.
 It will give you a completion report of the last Indexing/Packing
 run done by the program.


Display Files

FAMOUS uses text files which may be modified by you, to present
information to the user at various times.  These files all end with a
.TXT extension.  They are:

CHECKPAY.TXT - Displayed when a user purchases a service using a check.

EXPn.TXT - Displayed when n = the number of days left till the user
expires.

FREEPAY.TXT - Displayed when a user purchases a free Service.

GHOSTMNT.TXT - Displayed when a user tries to enter a FAMOUS module
while indexing is still under way.

NOHANDLE.TXT - Displayed when a user enters your system using only a
single name and the -NH parameter is being used with FAMFAST.

LOGON.TXT - Displays a short logon message while FAMFAST is processing
an ASCII user who is logging on.

LOGON.ANS - Displays a short logon message while FAMFAST is processing
an ANSI user who is logging on.

LOGON.RIP - Displays a short logon message while FAMFAST is processing a
RIP user who is logging on.

BDAY.TXT - Is produced by AGER and can be used with an autoexecuting
type 1 command to display users whose birthday is today.

PASS2.TXT - Displayed when a user enters the Forgotten Password Module.

USERS.INX - Ager will also produce a file called USERS.INX which may
            be searched via a Type 20 or displayed via a Type 1. This
            file is also used with the new ability for one user to buy a
            service for another. The file contains the
            Names/City/Expiration Dates of all non-invisible users.
            Included in this update are also USERS.DES and USERS.HDR to
            facillitate Type 20 searches.

Other files will also be displayed and are configured by you in the
system configuration for Welcome to a new user, Birthday greeting, Trash
Can message and when a user is automatically required to update their
user profile.


Authorizing Services

When you define a Service, you have the ability to have it take effect
immediately or wait for a specified period of time.  You may also
override that time period for credit card purchases/check
purchases.  But what happens when a Service is authorized immediately
and you later find out that the user's credit card has been declined by
the bank? Because FAMOUS allows you to specify how often it will pack,
get rid of deleted entries, it's databases, you have control over this.
When a service is authorized immediately, has no service length, and is
then applied to a user, it will be deleted.  It will still, however,
remain in the View/Authorize section of Accounting.  There, the sysop
may view it, and if he doesn't wish the user to retain it, remove it.
But that alone won't reverse the user to his previous state.  A new
service must then be applied that will do this.  To do that, you select
the particular service, in View/Authorize, and Go to the user's record.
There you must force a new service which has the ability to return the
user's capabilities back to another level.....and maybe display a file
advising him of what has occurred.  The View/Authorize area also lets you
override a Service's waiting period and authorize the service
immediately.  It will then take effect at the user's next logon.

Forcing Users

1. You can Force a Service on a user.

2. You can Change the user's Expiration Date which will force the
   default Expiration Service to take effect.

3. You can change the Last Update Date in the user's profile to Force
   the user to check the info he has entered into his profile.

4. You can delete a user, which will force him to re-register.

5. If you blank out a User's Logon Name, it will force him to re-register.


User Information

Each user record contains a wealth of information about the user.  Much
of this comes directly from the TBBS userlog and is refreshed/updated
every time a user runs FAMFAST as an autoexecute at logon or logoff.
Although much of the information you see may be modified by editing the
user's record, items like Calls Per Day, Flags, Priv level, etc. may
only be altered by assigning a service to a user that has been designed
to do that. The information will only be update, however, when the user
logs on/off.

You have a variety of ways available to you to sort through user
information.  Before you browse the listings, you may change the order
in which user information may be displayed by selecting the <O> item on
the menu.  This is a toggle which will loop through a number of
different ways of viewing the user listing.

Changing Basic User Parameters.

When viewing a user's record you may press <U>log Edit from the command
line.  This lets you change basic user parameters without the use of a
service.  On the user's next logon/logoff, FAMOUS will write those
changes to the TBBS Userlog and they will take effect. They will also
take effect if the user revises his profile.

Comments vs. Memos

FAMOUS has a single line comment field you can use to record free form
text about a user. In addition, you can use the <J>ot a memo function
which allows you to record ulimited free form text about a given user.

Verifying Users

FAMOUS has a toggle that lets you mark a user as VERIFIED.  This lets
you see immediately all users who have not been voice verified yet.


Service Pay Codes

Each service contains a 2 character code that identifies how it was
acquired. These codes ARE NOT the same as the Service ID codes and are
only accessible by the Sysop.  They are:

CC - Bought with a credit card.
CD - Cascaded from another Service
CK - Bought with a check.
ID - Acquired by correctly filling out the registration ID number.
SO - Forced, manually or automatically, by the Sysop.
BA - Batch Assigned by the Sysop.
NC - The service was 'Purchased' by the user, but was free.


Dates and Colors

FAMOUS sometimes uses colors to catch your eye for certain items.

In the User Database:

On the Browser User Listing, the Rec # will be:

Flashing White = Your User record.
           Red = User record has been deleted.
       Magenta = First Time User Today.
   Bright Cyan = Normal.
        Yellow = User record has been Tagged.
        White  = User has not yet been Verified

Within a User's record:

For the User's Expiration Date:

    Red = User Has expired.
 Yellow = User will expire in less than 15 days.
Magenta = User will expire in less than 30 days.
   Cyan = User's expiration is greater than 30 days from now.

For the User's Age:

    Red = User is less than 16 years old.
Magenta = User is less than 18 but greater than or equal to 16.
 Yellow = User is less than 21 but greater than or equal to 18.
  Green = User is over 21.

For the Special Flags:

    Blue = Off or No
  Yellow = On or Yes

When Viewing/Authorizing Purchases, the Rec #
will change to indicate the following:

    Red = Service is awaiting Authorization by You.
   Cyan = The Service has already been Authorized, but has not been
          activated yet.  This condition will occur if a user has not
          logged on since authorization took place.
   Blue = The Service has been Authorized and Activated.


When viewing the services in a user's record you will see 2 dates.
The first is either the date that the service was actually picked up or
the date that it is set to authorize on and the second is the date that
it will expire.  If the first date is cyan, it says that the service was
picked up on that date.  If it is blue, it is the date that it will
become active, and will activate on the user's next logon on or after
that date.

Service Field Descriptions:

This is a sample 1 year subscription service.  Field descriptions
follow.

----------------------------------------------------------------------------
                                Service Offering

         Rec #: 3
          Code: 1YR  Category: SUB
  Minimum Priv: 0 for Upward Cascade and Purchasing
  Maximum Priv: 255 for Downward Cascade and Purchasing
   Description: One year full system subscription
Offer to Users: Y
Service Active: Y
Cascade in: 0 Days to Code:
Age Service in: 90 Days if not picked up. 999=Never Age
Override Other: Y (Deletes any other Services Waiting to Cascade)
  Gift Service: N (Allows the user to buy this service for someone else)
       Renewal: Y If Y, Updates Renewal Date and Exp Date in User Database
 Active Status: 0 Change User's Active Flag: 0=No Change, 1=On, 2=Off

   Activate in: 5 Days. 0 = Immediate.
Activate Immediately for Credit Cards: Y Overrides above days for Cards
Activate Immediately for Checks: N Overrides above days for Checks

Character(s) for $: $   (i.e. $, £, DM, FR, etc.)
 Service Price:  120.00 Taxable: N or Free After: 0 Logons

User Info File: 1YR_SUB.TXT
                                Service Definition

Download (Y) or Display (N)N File: 1YRTHNKS.TXT

Change User Flags:  A1: -------- A2: ------   A3: XXX-..-- A4: --------
 Change User PRIV to: 75 (0-255, 256=No Change)

Delete User at next Logon: N  Change KEEP Flag: N Turn on Keep Flag: N
Change INVISIBLE Flag: 2 (0=No Change, 1=Invis On, 2=Invis Off)

 Net Mail Cred: 0   Replace: N
Change CM Flag: N   Crash Mail: N  Free Mail: N
Change FA Flag: N    Change to: N

Calls Per Day: 0      Replace: Y
 Min Per Call: 60      Replace: Y
  Min Per Day: 180      Replace: Y
Bytes Per Day: 1000000      Replace: Y
          Add: 0  to User's Actual Upload Bytes (- to subtract)

BC: 0  Hours: 0  Min: 0 or Rate:  0.00 Per Minute  Replace: N

Extend User's Expiration Date by: 365 Days (999=Never Expire) or
New User Expiration Date = Purchase Date plus 0 Days

TBBS Cmd Type: 0  Opt Data:

-------------------End of Service Definition------------------------

Service Field Descriptions

Rec # - Database Record number

Code - 3 character code.  Used for reports, invoicing, searching, etc

Category - 3 character code that is matched with a parameter in the Opt
Data line of FAMBUYER to only display those services.

Minimum Priv and Maximum Priv - These Privs form a 'window'.  Only users
who fall within the window may purchase this service.  When cascading,
if a user does not fall within the window, the service will not be
activated.  This allows you to do conditional cascading.

Description - A brief description of the Service which may be seen by
users

Offer to Users - If N, users will not see this service in FAMBUYER,
otherwise they will.  Allows services which are only available to the
Sysop for Forcing.

Service Active - Allows you to temporarily take a service offline.

Cascade in n Days to Code - The number of days that the service will be active
after which it will invoke the named service.

Age Service - Sometimes a service may be purchased, or attempted to be
purchased, and the user never calls back again to pick it up.  This
field allows FAMOUS to only allow the service to be 'on hold' for n days
after which it is deleted.

Override Other - Allows this service to delete any other services which
may be waiting to cascade.  Like a subscription service would override a
default service that was going to cascade to an expiration service.

Gift Service - Allows this service to be purchased by User A for User B.

Renewal - If Y, this will update the Renewal date in the user's record.
The Expiration date will also be updated based on the expiration date
information in the second screen.

Active Status - Allows you to change the user's Active flag.  This flag,
if set to Y will keep users from being aged, even if they have expired.

Activate in - this allows you to set a waiting period before the
service is activated.  The Sysop may override this period or remove the
service.  At the end of this period, if no action has been taken by the
Sysop, the service will automatically activate itself.

Activate immediately - These are two switches which allow you to
override the previous setting for different payment types,
i.e. Credit card users are activated immediately while Check users must
wait 5 days.

Characters for $ - Th content of this field defaults to your
configuration setting and allows you to specify the character(s) you
will use to designate money.

Service Price/Logons - This is what you will be charging the user for
purchasing this service, 00.00 = Free, or you can specify that he will
receive it automatically on his nth logon. You can also specify if this
service is taxable based on the tax rate set up in the system config
area.

User Info File  - When a User is in the FAMBUYER program, purchasing a
Service, he can request that more information be displayed regarding
that service.  If he does so, FAMBUYER will display the text file
identified in this field.  If this field is left empty, the user will be
informed that no more info is available.

The service definition screen defines exactly what this service will do.

Download/Display File - As part of the service you may allow the user to
download any type of file, or display a text file.  This may be used in
a variety of ways.  Such as:

 1. Display a Welcome Greeting
 2. Warning Message to twits
 3. A thank you for buying the service
 4. Clue to an online game they must buy, etc

If the File: field is left blank, this capability will not be used for
this service.

Change User Flags - Enter in the specific flags you wan the user to be
changed to.  Options are '-' No Change, '.' Off, 'X' On.

Change Priv to  - Any number in this field, except 256, will change the
user's priv to that new level.

Delete User/Change Keep Flag - Tells this service to Delete the user at
his next Logon.  Can also be used to turn on/off the user's Keep Flag.

Change Invisible Flag - Tells the service to change the user's invisible
Flag or to leave it alone.

About Replacing/Adding to:

Many of the next fields have an option to the right called Replace.
This is a switch which tells FAMOUS if it is to Replace the user's
current information with that contained in the field, or ADD to it.  For
example, if a user currently has 100 Net Mail Credits, and you put 10 in
the Net Mail Credit field and Replace = N, the user will then have 110
Net Mail Credits (100 Existing + 10 New ones = 110).  On the other hand,
if the user currently has 50 Net Mail Credits, you have 60 in the Net
Mail Credit Field, and you set Replace = Y.  He will end up with a total
of 60, because you are REPLACING the 50 existing ones with 60 new ones.
Not adding to it.

If you do not want to change a particular value in a user's record, set
the field to 0 and Replace = N.  The 0 will be added to the user's
current value which will keep him as he currently is. This is the
default when a new service is defined.

Net Mail Credits - Changes how many Net Mail Credits a user has.

Change CM Flag - Asks if you want to Change the value of the Crash Mail
Flag, and then what value you want to change it to.  Same applies for
Free mail (Free Mail even if No Net Mail Credits).

Change FA Flag - Allows you change the value of the Full Access Flag.

Calls Per Day
Minutes Per Call
Minutes Per Day
Bytes Per Day  - These fields allow you to change their corresponding
                 values either by replacing them or incrementing them.
                 To give a user the 'Unlimited' setting, set the field
                 value to 0 and Replace = Y


Add Bytes to User's Upload total - Allows you to 'seed' the user's
Upload bytes in the userlog.  This can be used in conjunction with
various File Management programs which look at Upload/Download ratios.
You may also substract bytes.  So, when a user first enters your system
you could seed him with 500,000 bytes. Then after 30 days, remove the
500,000 bytes since during that time he should have done some of his own
uploading.

Billing Class Time - You may specify any Billing Class, 0-9, and replace
or add to the user's existing time allotment.  You may also allow the
user to purchase time at a rate of $XX.XX per minute.

TBBS Command - You also have the ability to specify any type of TBBS
command in a service to be run.  This might be a QAL, a TDBS program, a
menu movement command or anything else. This is a very significant
addition as it lets you have users fill out profiles on their first
logon, configure their terminal settings, ask additional questions via a
QAL/TDBS program after n logons, buy access to a game, etc.

The Command will be the last thing run in the service, so any other
attributes that you are changing or file display/download will take
effect BEFORE the command is run.  If the user is purchasing this from
the FAMBUYER program, any type of menu movement command (Type 5, 12, 35,
45) or invoking an option module (Type 200, 205, etc.) will NOT return
him to FAMBUYER but will run the appropriate command.  Menu movement
commands will bring the user to the appropriate menu and drop him off
there. Option Module commands will run the appropriate option module and
leave the user at the menu which called FAMBUYER or FAMFAST.  If you do
not wish to run a command, set the TBBS Cmd Type to 0 (the default).
This option is located at the bottom of the second screen of the service
definition.


Extend Expiration Date - This allows you to adjust FAMOUS' expiration
date.  You may increment it by a number of days, or set it to the
service's purchase date plus n days.  When this date expires, the user
may be aged if his Active flag is set to N.  The default expiration
service, specified in the configuration section, will also activate at
the user's first logon after this date has passed.  Extending the
expiration date allows you to offer time limited subscriptions and
renewals.  A value of 999 in this field will offer a user an unlimited
expiration date.  This may, of course be overridden by the Sysop by
editing the user's record and changing the expiration date.



Offline Label/Report Definer FAMRL.EXE

FAMOUS incorporates a very flexible way for you to define and print
labels and reports in an offline environment using FAMRL.EXE to define
label and report templates and AGER.EXE as the actual printing engine.

FAMRL is used to design and generate .LBL files for labels and .FRM
files for reports.  These files are then defined for use in the online
sysop module, FAMSYSOP, through the offline Report/Label Queue manager,
options <B> and <C> on the main sysop menu. The queue managers let you
define a print job and place it into the queue for nightly printing.
The output is directed to either LPT1, COM1, COM2, or to a disk file.
If the output goes to a disk file, the file will be named after the form
being used with an extension of .PRN.  If you have multiple print
jobs queued to run using the same form, they will overwrite each other
if they are being directed to a disk file.  So it is best to use
different form names. You can create just one form and copy it several
times, renaming it each time.

Creating/Modifying Reports

The report definitions you can design are standard columnar reports with
report and column headings.  When totalling numeric columns, you can
have up to 2 levels of subtotals and generate a grand total for each
column.

To create or modify a report form, select report from the main menu. You
can create a new form by entering a new file name or modify an existing
one by selecting one from the pick list.

After selecting a form, you will be presented with a column definition
screen where you can design a new report or make changes to an existing
one.  This is where you add/change/delete columns that are to be in your
report.  Each form can have up to 24 columns defined.  Columns will
appear in the resulting report in the order in which you define them.  A
detail line will be displayed for each selected record from the User
Database file.

A report column is defined by entering each of it's attributes on the
column definition screen.  To do this, move the cursor to the setting
that you want to define and type in the corresponding information.  To
add subsequent columns, press Page Down, which will take you to a new
column definition screen.  When several columns have been defined, you
can use Page Up and Page Down to navigate back and forth.

Each column definition has a contents field, a heading, and a number of
formatting attributes.

Contents:

This field will contain a database field name from the FAMOUS database
USERS.DBF.  Most of these fields are defined later on.  The USERS
database contains a wealth of information that you may report on, such
as:

Logon Name
Real Name
Address, telephone, etc.
Upload/download bytes
Expiration Date
Renewal date
Group IDs
Time on line
Last Call
And much, much more

Heading:

The Heading is the descriptive information that will appear above each
column and may be up to 4 lines deep

Formatting:

Width defines the display width of the current column.  If the column is
based on a character field, like User_Name, any information which
exceeds the width will be wrapped to the next line in the column.  If it
a numeric field, like Up_Bytes, and exceeds the width, the entry will be
filled with asterisks.

Decimals:

Defines the number of decimal digits.

Totals:

This determines whether you want to have this specific column
totalled.  Three levels of totalling are available when the totals
setting is Y.  A grand total prints after all other report lines print
and, if there are groups or sub-groups defined, a subtotal prints for
each level of grouping as well.


Defining Report Options:

Columns are only a part, although a major one, of the entire report
definition you can create.  There are also options you may specify which
apply at the report level.  For example, headings and margins apply to
the entire report rather than an individual column.  To change the
default report layout press F2 Report.

Page Header:

This will print up to a 4 line header at the top center of each page of
the report

Page Width:

Determines the number of characters allowed for the combined width of
all report columns.  The default is 80.

Left Margin:

Determines the number of characters that the report will be indented.

Right Margin:

Should always be set to 0

Lines per page:

Determines the number of lines to print per page before an EJECT is
issued.  This number includes the page heading, column titles, detail
lines, and total lines.  Normal is 58.

Double Space:

Allows you to have report detail lines double spaced.  Normal is No.

Page Eject before print:

Determines whether a form feed is sent to the printer prior to the first
report line.

Page Eject after print:

Determines whether a form feed is sent to the printer after the last
report line.

Plain Page:

If Y, the page heading, page number and report date are not printed and
the report form heading is only printed on the first page.

Defining Groups:

FAMRL allows you to define two levels of grouping in order to summarize
information from the User database.  This grouping can only be used when
user records within a group are in consecutive order.  Normally, FAMOUS
will group user records alphabetically, so this function has limited
value at this time.


Creating/Modifying Labels

By selecting Label, as you did with report, from the FAMRL main menu,
you may also define specific formats for label printing. As with
Reports, you may edit an existing label form from the pick list or
create a new label format by entering a new label name.

The label definition screen is divided into two sections - Label
dimensions and formatting and contents.  You may move between the two
sections by using the F2 Toggle key.

Defining the Label Dimensions and Formatting

Width:

Determines the horizontal width of an individual label.  This value may
range from 1 to 255.  The default is 35 characters.

Height:

Determines the vertical number of lines in an individual label.  This
value may range from 1 to 16 lines.  The default is 5.

Across:

Determines the number of labels that will be printed across the page.
This value may range from 1 to 255.  The default value is 1.

Left Margin:

This determines the left margin and the first print position of the left
most label.  This value may range from 0 to 255.  The default is 0.

Line Between:

Determines the number of blank horizontal lines printed between labels.
The value may range from 0 to 255.  The default is 1.


Spaces between:

Determines the amount of vertical space printed between labels if the
number of labels across is greater than 1.  The value range can be from
0 to 255.  The default is 0.

Remarks:

This is a comment field that contains standard label format size
definitions.  This field may be customized with your own label format
size definitions.

Standard Label Formats:

Instead of specifying the dimensions and formatting criteria directly,
you may select a standard label format from the F3 Formats menu.

Defining Label Contents:

After you have defined the label dimension and formatting attributes, F2
Toggle will move the cursor to the contents section in the bottom half
of the label editor.  It is here that you will define the actual
contents of each label row.

This is where it can get a little tricky, since you are also allowed to
use several Dbase type commands to format the information.  For example,
lets say you want a label formatted as:

  Real_Name
  Address
  City, State
  Zip

Well, each of these is a separate field in the User database.  So how
would you get City and State on the same line ? Easy!  All you have to
do is to remove any spaces from the field CITY, concatenate (add) them
together, with a comma and space in between them.  Like:

  AllTrim(City) + ", " + State

Some useful commands are:

   AllTRIM() - removes all leading/trailing blanks
   +         - Concatenates 2 or more fields
   " "       - Defines a literal field, like the comma/space in the
               above example.
   UPPER()   - Turns the field into Upper Case

These commands do NOT affect the data in the USER database, only the
printed output.  It is not my intent to teach dbase programming, which
is why I'm only mentioning a few basic commands.  For experienced Dbase
programmers, however, additional commands may also be used, Like
TRANSFORM(), RTRIM, LTRIM, STR(), DATE(), etc.

Another example, based on the first, would be to make everything upper
case, and place the Zip code on the same line as the city and state.
Like:


  Upper(Real_Name)
  Upper(Address)
  AllTrim(Upper(City)) + ", " + State + "   " + Zip

A further example would be if you wanted to add a special mailing code
to the label so that users calling your system as a result of a mailing
would be able to insert the code in order to get special services.  You
would then be able to see how many users responded to a give mailing.

There are 2 ways to do this:

1. Insert a hard coded mail code to the label.  Like:

  Alltrim(Upper(Real_Name)) + "    123456"
  Upper(Address)
  AllTrim(Upper(City)) + ", " + State + "   " + Zip

  This would print out as:

  JOHN SCHACHAT    123456
  123 CHERRY TREE LANE
  ANYTOWN, CA   95124

2. A better way is to use the mail code that you defined in the Label
Queue. To do this, a special field is required which is not present in
any of the databases, but will print whatever you designate as the mail
code.  Remember, it may be placed anywhere you wish on the label.  The
special field name is: LLABEL_CODE.  For example, lets say that I wanted
the code to print at the bottom of the label, preceded by the words
"Registration ID: ".  Simple!

  Upper(Real_Name)
  Upper(Address)
  AllTrim(Upper(City)) + ", " + State + "   " + Zip
  "Registration ID: " + LLABEL_CODE


  This would print out as:

  JOHN SCHACHAT
  123 CHERRY TREE LANE
  ANYTOWN, CA   95124
  Registration ID: Mailing Code

Or, to place it alongside the user's name:

  AllTrim(Upper(Real_Name)) + "   Registration ID: " + LLABEL_CODE
  Upper(Address)
  AllTrim(Upper(City)) + ", " + State + "   " + Zip


  This would print out as:

  JOHN SCHACHAT  Registration ID: Mailing Code
  123 CHERRY TREE LANE
  ANYTOWN, CA   95124



Famous Database Layout For USERS.DBF

This information may be used when defining a report or Label using
FAMRL.EXE. I've only included descriptions for fields which might be
applicable in a report or label.

Data Types are D=Date, C= Character, L=Logical, N=Numeric.


Field Name    Type    Length   Description

REAL_NAME      C        31     User's Real Name
ADDRESS        C        40     Street Address
CITY           C        40     City
STATE          C         2     State - Abbreviation
ZIP            C        10     Zip Code
COUNTRY        C         3     Country
TITLE          C        31     Title
USER_NAME      C        31     User's Logon Name
SCHOOL_NAM     C        40     Company
DISTRICT       C        31
EMAIL_ADDR     C        40
DAY_TEL        C        14     Daytime Tel. Number
FAX_TEL        C        14     Fax Number
LAST_LABL      D         8     Date Last Label was printed
UPLOAD         L         1
DOWNLOAD       L         1
INTERNET       L         1
DATE_ENTER     D         8     First logon Date
COMMENTS       C        64
LAST_UPDAT     D         8     Date record was last updated
CRDNO          C        19     CC Number
CRDNAME        C        31     CC Holder's Name
CRDTYPE        C        10     CC Type
CRDEXP         C         5     CC Exp. Date
AUTHORIZE      C        20     CC #
AUTH_DATE      D         8     CC Authorized Date
UP_BYTES       N        12     Bytes Uploaded
DWN_BYTES      N        12     Bytes Downloaded
EXP_DATE       D         8     User's Expiration Date
RENEW_DATE     D         8     Date User Renewed
ACTIVE         C         1     User Active Y/N
LAST_CALL      D         8     Date last called
LAST_TIME      C         8     Time Last Called
NUM_CALLS      N         7     Total Calls
LAST_SPEED     C         6
LAST_LINE      C         2
LAST_SEC       N         8
START_SEC      N         8
TIME_ON        N         8
ANSI           L         1
RIP            L         1
A1             C         8
A2             C         8
A3             C         8
A4             C         8
PRIV           N         3
SPEC_FLAGS     C         8
ANS1           C        60
ANS2           C        60
ANS3           C        60
ANS4           C        60
ANS5           C        60
ANS6           C        60
ANS7           C        60
ANS8           C        60
ANS9           C        60
ANS10          C        60
USER_TYPE      C         1
NM_CREDITS     N         6
NM_DEBITS      N         6
TAG            L         1
LAB_RESP       C        15
L_TAG          L         1
INVIS          C         1
GROUP1         C        10     Group 1 Name
GROUP2         C        10     Group 2 Name
TOT_TIME       C         7     Total Time Online
MPC            N         3     Minutes Per Call
MPD            N         4     Minutes Per Day
BPD            N         8     Bytes Per Day
CPD            N         3     Calls Per Day
B_DAY          D         8     User's Birthday


                              More on RIP

This is NOT a tutorial on RIP and I do NOT claim to be an expert.  That
said, here's some hints about RIP. First, RIP is an immature protocol
that is constantly changing.  If there is any line noise that disrupts a
user's data stream the results can be disastrous.  Since RIP is a
command-oriented protocol, any commands that get garbled will
dramatically alter any commands which follow.  This is unlike ANSI,
where the user will at least be able to access a usable screen.  Since RIP
commands also control the mouse, which is the way data is input to the
system in many cases, it is possible that even the user's mouse will
become disabled under noisy line conditions.

In TBBS, we send a series of commands to the RIP terminal emulator,
which is running RIP.  These commands are usually only sent once.  The
emulator then paints a screen for the user, based on these commands and
designates 'Mouseable areas'.  These areas, when pressed, send commands
to the TBBS system.  For example, if you press the 'A' key on the
FAMFAST/FAMUSER keyboard, it will send an upper case 'A' to TBBS from
the terminal emulator.  TBBS has no idea that it's dealing with a RIP
terminal emulator, it only knows that it got an 'A' and will respond if
it's appropriate.

RIP allows different kinds of windows on the terminal emulator.  With
FAMUSER.RIP, we've incorporated a text window and a data window.  The
text window is where the TBBS data will appear. The Data window is
essentially everything else.

So what does it all mean?  Well, you've got to be careful.  If a RIP
user calls in, not using an error-correcting modem, he can get garbled
commands which may be difficult for him to get rid of.  And you'll need
to refresh the FAMUSER.RIP keyboard, or whatever you're using.  How do
you do this?  It's surprisingly simple.  You need to send a new series
of RIP commands to the user's RIP terminal emulator.  This can be done
very simply with a type 1 command.  Like:


   Entry: <R> Refresh your RIP keyboard
   Priv = 0
   Key = R
   Type = 1
   Opt Data = C:\FAMOUS\FAMUSER.RIP /NK

That simple.  A type 1 command will send the appropriate RIP command
sequences to the RIP emulator and tell it to refresh itself.  It is a
good idea to have these scattered around, or as autoexecutes which will
kick in after a RIP application finishes.

Another file has also been included called RESET.RIP.  When displayed
with a Type 1 command, this file will remove the FAMUSER.RIP template
from the user's RIP terminal altogether.  It may be invoked as an
autoexecute or as a menu item.  Like:


   Entry: <R> Remove the RIP keyboard
   Priv = 0
   Key = R
   Type = 1
   Opt Data = C:\FAMOUS\RESET.RIP /NK

---------------------------End of Document---------------------------